Well, I certainly agree that JVM or CLI bytecodes are not optimal to serve for system-level code.
But x86 isn't that good either, so a better machine-language code is needed. Then there's an absolute dependency on having a garbage collector. You can't have flat RAM, manual memory management and security at the same time (it's a 'choose any two' situation) because it's trivially easy to exploit dangling references.
Then you have to have mandatory boundary checks and limited pointer arithmetic.
So as a result you get something that looks a bit like Java or CLR from the logical point of view and much less like x86 machine code.
E2k doesn't really solve it (as someone who knows a few folks from MCST - E2k doesn't really solve ANYTHING). It has hardware tagging for pointers, so all pointer arithmetic instructions are privileged operations. That can be used as a hardware assist for low-level secure OS, but in itself it's certainly not enough.
And NaCl still relies on hardware memory protection to contain untrusted code, so it's just a clever way to implement lightweight virtualization on x86. Qemu or VMWare both do similar tricks as well.
So to recap this, I believe that a future OS is going to use software-enforced isolation. Probably aided by a more suitable hardware architecture than x86. It most probably won't use bytecode format of current virtual machines, but it would functionally similar to them.