I agree with DonXML when he questions the value of making Edit and Continue a part of your development process.  To add my $.02 to the debate, I can see this being misused in a number of ways.  Take this for example:  You're debugging, you encounter a bug.  So, you inspect an object in the Immediate window, find the property with the value you're looking for, add it to your code, and voilà.  Your code runs! 

The big problem I can see here is coding to some value of some field at runtime!  Now hopefully most developers won't do this, and will actually use it to say “Oh yeah, dumb mistake, I need to fix this.”  But I have a feeling that many developers will begin to use the debugger instead of intellisense or framework documentation to find out what interface to code against.

I've been guilty of this myself.  I wrote a bunch of pathing code to determine runtime paths for ASP.NET.  I figured much of this out by inspecting the Request object's properties at runtime.  What happened?  The shit broke, that's what happened.  The problem was I didn't understand the objects I was using, I was just programming to what looked good at runtime.   When the runtime environment changed, it broke my app.

Now,  Microsoft doesn't seem to be interested in fundamentally changing the way we develop code.  They're never going to develop tools that support agile methods first.  To do this would be to alienate 95% of the developers out there.  They want VS to fit into your existing development process, no matter how screwed up it is.   And you can't blame them.  They're trying to make everyone happy - they're selling software. 

So, I guess what I'm saying is we can't really blame them for adding features that are going to be mis-used.  Keep yourself disciplined.  Use these things only when you really really need them, like right before a deadline.  ;)

-Brendan