I don’t have information authoritative and I think it largely depends on the specific implementation that can change as needed.
In C# and VB.NET it is more or less easy the real code that is executed to be generated at runtime through the Jitter, then there is already a compilation in the execution even when it will not use the Edit and Continue. Of course it’s a more limited compilation, it only takes one bytecode and generates the executable code. Jitter can compile only what matters, it can even recompile something if it thinks it is necessary (as far as I know . NET does not do this, but could as optimization during execution when identifying a hot path).
I believe the recompilation of bytecode occurs only in the modified method, but this depends on the implementation.
The recompilation of the source in bytecode could occur only in this method, but has a chance to be at least in the whole file of it to check that everything is right there in that source. The .NET Compiler Platform was created to be able to compile only parts of a code, even a smaller part than a method, although this will be useful in very specific circumstances.
There is probably the insertion of metadata and even dead instructions (nop) in code generation to facilitate recompilation.
Done the recompilation the Jitter will use some strategy to replace the code, or putting in the same memory area (maybe even making a deviation), most likely, or updating the references contained in every application to the method in new address.
As you have already noted it is only possible to change imperative code (with limitations), you cannot change the data structures. But you can create new ones.
In C++ a larger infrastructure is required because it does not have a Jitter. I mean, you kind of end up having to put a Jitter in the app just to do this.