@Cerebus and Bekdik: I agree that is one perfectly possible approach.
But to accomplish an RT-based windowing environment on the Desktop would require a further abstraction of either RT and Win32 or the Desktop, so they could call a common UI as required. That adds another layer in the architecture, with attendant security and performance penalties, and makes Windows even more byzantine - exactly the opposite of MSFT and industry direction.
To bring out two separate versions is certainly an easy technical decision, though rather more nettlesome from a marketing viewpoint. I know this was hugely debated inside MSFT, with many compelling arguments in favour. From a technical viewpoint it's pretty easy. One reason why it's less attractive is because it re-establishes a dual code base for Windows (much like the old days when we had DOS+Win on the one hand, and NT codebase on the other).
Another reason is that both the industry and Microsoft direction is to integrate and harmonise across platforms. The vision is a fully scalable system, from server through desktop and mobile to imbedded, with common services and important APIs. In addition, requirements for manageability, security, BYOD and a whole host of other imperatives (such as more capable power-misely hardware) you know only too well are driving ineluctably to greater commonality, not further fragmentation.
Add into this stew a whole consideration around hardware architectures and marketshare, essentially this boils down to Intel vs ARM. Today Intel (with MSFT) dominates the server and desktop/notebook market, and ARM dominates mobile (tablet and smartphone). But will that always be the case? What if Intel matches or surpasses ARM on performance, energy efficiency and low price, and does it with the x86 instruction set? How does that change the future?
My own suspicion is Microsoft has sight of Intel plans not many others see.
However, whether Intel does or doesn't is in a way beside the point. ARM is here now, and millions upon millions of devices this year and next year and perhaps the year after will use it. So this has to be addressed or MS will be marginalised into utter obscurity in an important space (if it hasn't already). (On this point, WinRT on WP8 has always been the plan; it just took longer than expected to bed down WinRT specs, so WP7x was an 'interim emergency' release to hold the place until WP8. But I digress.)
That said, Microsoft are in fact doing exactly that: releasing two code bases (Win8 x86, and Win RT for ARM). But they are making sure the "full blown" or "professional" Windows can also run the tablet apps, because if it couldn't we'd have the untenable situation where desktop PC Windows couldn't run "new" Windows applications that the tablets can. The flagship Windows (on the PC) must be able to run any Windows applications (be they Win32/Desktop or WinRT/Metro).
Already established is:
* Win32 provides the essential application compatibility that makes Microsoft successful, but it is (unavoidably) riddled with (integrity and security) vulnerabilities carried over from old real mode and protect mode architectures from the 80s and 90s.
* Intel on x86 have not successfully addressed the burgeoning tablet/smartphone market, letting in ARM on hundreds of millions of devices using iOS and Android. Because of the x86 tie, Win32 is similary unable to address this market.
* Win32 is beyond mature - it is almost entering old age. It cannot take MSFT to where it wants and needs to be in 2020.
* WinRT (the API set, not the confusingly-named Windows on ARM, also called Win RT) is the strategic API set to replace Win32, and the sooner the better. It is not tied to x86 as Win32 is. It is where Microsoft wants to transition future applications.
So, how to transition from Win32 to WinRT? We can't stay where we are, and we can't introduce is new and incompatible platform and credibly call it Windows when it can't run legacy Windows applications.
Here's the nub: The only sane transitional move is to make a Windows that runs both the new WinRT, and yet can also run the current (ie 1980s architecture) Win32.
That is what Win8 does. And frankly, for Microsoft, any other alternative has too many downsides.
The challenge for Microsoft is how to introduce WinRT as its main "architecture for the future" and transition the massive installed base from Win32 to WinRT without endangering the Window franchise and letting in the competition. This transition is pretty easy for a small and forgiving adulatory installed base like Apple's (they did it from MacOS to a rejigged NextStep). But for 1.3 billion users and most businesses infrastructure it's a supremely awesome challenge. Get it wrong, and not just Microsoft will disappear but much of the benefit we see today in the global industry around a common target platform.
So, WinRT has to come because Win32 cannot get us to where we want to be.
When you consider all the options in great detail - and believe me, they have been debated and viewed from every conceivable angle inside Microsoft. The question in the end answers itself: at some point, flagship Windows must include both Win32 and WinRT.
Microsoft is deeply and implacably committed to the PC. And it recognises the opportunities on the newer hardware platforms (tablets and smartphones - it's been there for many years and loooong before the iPhone, iPad and Androind). But the Win32 legacy and Intel's failure on mobile x86 has caused a serious stumble and loss of opporftunity and share.
Windows 8 brings in WinRT - by far the most important long-term change in Windows, but completely invisible to 99.9999% of users, but critically important to developers.
WinRT is modular and flexible enough to transition easily to any platform, including ARM, something not possible with Win32.
So, to summarise:
1) At some point, Windows necessarily must include both Win32 and WinRT, for the reasons touched on above.
2) Architecturally, the new RT-based apps will run on any RT-enabled platform, from server to desktop to tablet to smartphone. Obviously these have very different display and MMI capabilities, so a scalable UI has to be developed (Metro is Version 1.0).
3) For deep technical reasons, WinRT and Win32 cannot call the same UI, so whatever you do you cannot have them side by side on the screen without sabotaging the whole reason you're moving away from Win32 and implementing WinRT (which must happen if MS is to survive beyond 2020).
4) There is nothing in the Metro architecture that makes it necessarly full-screen. The current version and definition is fullscreen, but there are other reasons for that, not the least being that in this transitional phase even more confusing would be to have to completely independent windowing UIs on the same system. The added advantage now of a full-screen "immersive" Metro environment is that it can be leveraged across platforms. But that can and might change in the future.
5) Precisely because Microsoft is so committed to the PC, it makes a lot more to sense to ensure that the "main strategic" Windows platform supports everything that can possibly be called Windows and Windows applications, ie legacy Win32 apps (in Desktop), as well as new/future WinRT apps (in Metro). If this makes sense (and any alternative doesn't), then dual environment UI is the only choice, ie windowing Desktop for legacy Win32, and Metro (which today is fullscreen for good reason, but won't necessarily always be).
On the tablet/smartphone, you can bring WinRT-only, without support for legacy Win32 apps as these in any case are not feasible or even desired on most of these devices. It also means these platforms can give added impetus to WinRT app development, which can then be leveraged back into the strategic mainline desktop Windows systems, setting up a mutually reinforcing virtuous circle in app development until we figure out what Metro 3.0 will be like.
(ctd below)
Can't wait 
