The more I read/watch about WinRT, the more it seems the list of "things you can suddenly do" seems inescapably identical to the claims being made nearly 10 years ago for the CLR.
A common type system (which in fact builds on a metadata format taken straight from the CLR), a common platform that multiple languages can interoperate with, a big and ever growing library of APIs exposed via that platform, starting with a common system of collections, and then a common way of doing generic types, etc.
Just as C++/CLI meant that C++ was part of the CLR environment, in precisely the same way we now have C++/CX for WinRT as described in this talk. As the team discovered, C++/CLI has a lot of good stuff in it, so it just makes sense to do it that way. One reason for this is that the CLR (while by no means perfect, lacking multiple implementation inheritance) has a lot of good stuff in it, and C++/CLI was an elegant projection of that feature set.
IL code can have pointers and can so corrupt the entire process address space if it feels that would be helpful (available in C# via unsafe code). So that is not a unique capability of native code. Again, CLR and WinRT are (sadly) of one mind on that score.
So far all I've been able to detect that is different between the two is that CLR has a compacting generational mark/sweep garbage collector and WinRT does not.
Viewed from this angle it seems largely like an exercise in repeating the entire CLR design program but this time not using a sophisticated GC, substituting in its place very basic reference counting in a free store, per OLE circa 1990.
Is there anything being announced here that could not have been achieved by building the whole WinRT atop the CLR? Bearing in mind that Herb's advice (use ISO C++ everywhere except at the boundaries) could also be followed in exactly the same way in C++/CLI.
The flat memory space is just an abstraction. It is not necessarily a more fundamental underpinning than any other (it has to be simulated by the virtual memory system). And if you are concerned about security, it's a poor choice of abstraction for application programming, to judge by the constant stream of exploit opportunities being discovered and patched in code that has buffer overruns, dangling pointers, etc.
So, not a step backward (because all the old stuff is still there), nor a step forward (because it so closely resembles a subset of the old stuff). A step sideways?
The piece I'm missing from all the talks/articles is a justification, a philosophical basis, an over-arching motivation, for why Microsoft needs (and MS thinks the world needs) something exactly like the CLR but without the GC.