You don't. Worst case is you had wrong assumptions and restart the program, same as if you didn't have the ability to change things.

Best case thought, it's so useful. It's also incredible for editing tunables on the fly(think videogame gameplay values, layout values for UI, etc).

Worst case is you don't know you broke consistency. Then you can waste hours hunting for ghost bugs that only occur because of the hot-code-reload.

As someone who worked on dynamic updating research projects for years I can attest to the really shitty bugs dynamic updating can cause.

Editing tunables is possible without recompiling new code. It's just setting the variables to new values.

Not if you want to change the formula the the tunable uses.

In Smalltalk, most of the class library, and hopefully your own codebase, is either side-effect free or at least well encapsulated. The classic trip-up in Smalltalk was with Streams. An experienced Smalltalker would make note of where the code was fiddling with Streams, then go down the stack until the debugger has effectively gone back in time before the Stream objects were instantiated. Try that for a few seconds, then restart the app. If your environment was set up intelligently, none of that would take that long.

I believe changing data structures gives a "you must restart to make this change" when resuming debugging. It's mainly for code flow type bugs rather than data structure type bugs.

For things that require restarting in Visual Studio, look in the docs for the topic of rude edits.

If the data structures in memory don't fit the new code, I suspect that's a compiler bug.