The biggest problem with this is that it eliminates OS-specific facilities, such as the clipboard, OS-style text selection, right click menus, window styling, etc. Yes, these features could be reimplemented, but they are very hard to get right, and near impossible if you are trying to match OS behavior on many platforms.
This suggestion is fundamentally no different than exposing a <canvas> element to a page, and saying "OK, implement your own rendering engine and draw whatever you want in this box." Let's say you wanted to implement a modern browser engine in the canvas, like WebKit. Well, you'd need a huge number of OS specific hooks to get things like the ones I listed above. Do you expose those via an OS API? Well, you just opened a huge number of vectors for an attack. Do you replicate these hooks in your own code? Well, you just created a crappy UX since you're never going to match the OS behavior 100%.
The comparison to the browser based web seems like a bad way to sell the idea. Not managing a huge stack is a pretty nice feature, and the comparison invites people to imagine managing the whole stack.
Why not just call it a sandboxed environment and delivery mechanism for untrusted native code?
Then a browser implementation demonstrates how great the security model is and how rich/capable the environment is.
This suggestion is fundamentally no different than exposing a <canvas> element to a page, and saying "OK, implement your own rendering engine and draw whatever you want in this box." Let's say you wanted to implement a modern browser engine in the canvas, like WebKit. Well, you'd need a huge number of OS specific hooks to get things like the ones I listed above. Do you expose those via an OS API? Well, you just opened a huge number of vectors for an attack. Do you replicate these hooks in your own code? Well, you just created a crappy UX since you're never going to match the OS behavior 100%.