"Correct" may depend on your point of view

Correctness from the debugger's perspective is very different than correctness from the end-user's perspective. For example, the debugger exposes many invasive operations like SetIp. The debugger considers the operation successful if it sets the IP to the target line. However, doing that may violate the program's natural control flow and thus may be considered incorrect from the end-user's perspective. A language service may sit on top of the raw debugging services to try to restrict these invasive operations to have some consistency with the source language.

This is probably the biggest issue with Edit-and-Continue (EnC) and func-eval. We talk about "legal edits" but find that to be ambiguous: legal from the CLR's perspective; legal from the language's perspective; or legal from the end-user's perspective? For example, you could add an 'if (false) { ...}' around the current line. At the CLR level, that's just adding some jump opcodes into the IL, and so it's a perfectly legal edit from the CLR's end. But at the source-level, it could be confusing.  There are countless other similar examples. For example, what should modifying a for-loop's condition check do? Again, this is just a trivial IL change from the CLR's perspective. From the language or end-user pespective, this can introduce great inconsistency. The language-services have additional checks to try to enforce sane edits.

The debugger has several invasive operations that can change the programs behavior:
Edit-and-Continue (EnC) : see examples above.
SetValue: you could set a variable to a value that it could never hold. You could null out certain values.
Func-eval : This is just evil. You could execute arbitrary code in a way that it was never intended to execute
SetIp: You could set the IP in a way that could never happen with normal control flow. For example, you could opt out of a loop early, or potentially skip validation checks.