It's pretty cool but how many times would this really useful in a real world case?
Edit & Continue is the closest thing we have but that doesn't (yet) work for 64-bit code. Not quite as slick, but putting a breakpoint and then changing the code while stopped in the debugger is not that far behind what the demo shows.
Plus, I would say the cases where this kind of stuff is useful is where it takes a long time to get the app into a particular state so that it even executes the code you are working on. At that point, not having to stop the code when changing it doesn't add a whole lot. Plus this would only work if the code is executed repeatedly.
The way I usually use E&C is to break at the start of the method, make the changes, then run to the breakpoint after the code that got changed (or just single-step through it). If it still doesn't do what I want, I just move the execution point back to the start of the method, make some more changes and repeat the process. I've used this technique to flesh out a full method starting with an empty method. So what the demo shows won't help much for those use cases unless the code is running in a loop.
Still cool though.
EDIT: In fact I think there is an advantage in breaking into the debugger first in that you can see the values of the relevant variables.
Not to go too far off topic but I think it is somewhat relevant... A while back I was working on a VS plugin that gave you a "Live Watch" window. So just like the current Watch window, you can add variables to it while in the debugger. But when you run the program again, the Live Watch window would give you the current value of the variables you added. It is useful to keep an eye on various variables as your program runs, to see what happens over time or how some interactions cause variables to change. It actually ended up working quite well, but like so many other pet projects, when I got to the 90% completion point, I kinda lost interest.