For me, this whiteboard session was summed up very well at the end (sorry - don't have a time-mark off the top of my head): If we're building an distributed set of services that require implicit "synchronization", that is, contracts must be in sync, type knowledge must be available to everyone, etc., than what we've actually built is ONE BUSINESS SERVICE connected by distributed technologies.
By contrast, as soon as you try to connect MULTIPLE BUSINESS SERVICES, developed by different teams/companies, different timezones/locations, different languages, toolsets (make sure you include vim/emacs here even if you don't agree with it), all of these "benefits" (of "pixie dust" as Clemens puts it) begin to vanish very quickly. You simply cannot force that type of orchestration across companies/teams/locations/timezones without paying a heavy price. I've worked at at least two companies that have tried, and they end up getting buried by their own processes.
IMO, either of these models is acceptable - so long as we're cognizant of the implications of the systems we're building. That (from my point of view) was the real point of this session....not a religious debate over some ultimate right-and-wrong (or "best" practice, whatever that means).
As always, use what works for you and your specific application - but understand you can't have both. Much like the "static v. dynamic" debates, if you want a language that allows dynamic features, you're going to have a bad day if you try to do that with a static language. Likewise, if you want complete decoupling between services (no really - 100% decoupling, not just a separate project in Visual Studio), you're going to have to build them differently (regardless of technology you're using).
On second thought - never mind. There is a *ton* of money to be made by selling VS2012 licenses, and if the masses ask for it, then there is no reason for MS to not make it. Remember, you don't have to use it, although they'll probably bake it into every project template they can without even asking.
Anders, et al - **please** think about the long-term implications of this. MS has failed the developer community many times on VS-specific things in the past...take this (potentially) good idea to ECMA, and drive the standard. Good tooling will follow.