@bondsbw: That's something I've wanted on another project. The ability to add new trace stuff at runtime "add logging statements on-the-fly" - if that really works without pausing the app, could also be useful with the "edit and commit".
With the "edit and commit" - edit without pausing the app, it's useful to get a coarse idea of what is going in variables. This is really no different than if you were debugging some sort of analog circuit with a digital scope. The circuit(or app) goes into state where it's doing stuff and you get a snapshot (poke your probe around the board with single-shot triggering on the scope) of the data. eg. easiest to understand example would be if you had a half-broken audio synthesizer hardware. You would not power it off to fix or tweak the sound but place ability to make adjustments (like tiny internal trim pots) while running*. And by "broken" I mean that perhaps the audio did not sound nice, maybe there was a repetitive glitch only after the device was in certain state etc.
Now I'm willing to leave it open how should this runtime editability be implemented - so far I've suggested you might just have the ability in something like the CLR but another way to do it is to have a C# console app template that creates all the boilerplate needed to have 1 app running and another editable, then you can "failover" the running app to the edited version and these could be located on different computers. I imagine this would be somewhat similar to cloud development but without needing cloud. Because lets face it, if I'm doing a game engine or driver or whatever, do I want cloud? Not really... But I still need ability to tweak things at runtime and I may also need ability to failover things such that the production executable is on embedded hw or simulator and the 'being edited' version is on the VS side- so then I just failover the stuff on the hw-sim to the edited version such that instead of 1 second cross platform compile times it will be <1 millisecond operation.
So there's few ways to architect this and once you have it, you want ability to also monitor the variables at runtime, just like if you had n+ channel logic analyzer sitting on all the bus on the hardware waiting for a condition to occur so you can get short view of what went on just before and after the condition/glitch.
(* with hardware you can actually pull and add stuff into the circuit without powering it off if you understand what kind of changes can be done without risking component failure - and of course the more failure prone things can be either designed or dealt with specific order)