The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

I like the rest of your post, but this sentence is a little short-sighted. If there's anything that the march of progress in computing has taught us, it's that if the capability is there, someone will invent a useful demand.

Look at HTML, look at Javascript, look at all that: what have webprogrammers been doing for the last decade? Yes, a browser is ALREADY A VIRTUAL MACHINE RUNNING YOUR APP. That is where this was all going! HTML+JS was just ONE instance of that, but you could allow any kind of bytecode/machine code/whateverexecutablething for the same effect.

Yes, this is a good generalization and an interesting idea. But I would argue that HTML+JS, or even Java, is still better than using native machine code. My main beef with this NaCl system has to do with the fact that x86 isn't the only platform out there. FTFA, every NaCl app already has to be compiled twice -- once for x86-32, once for x86-64. How many web developers will bother to also recompile their app for ARMv7, PowerPC, Itanium? When we all migrate to the latest and greatest ISA for our mobile devices in 2025, all the closed-source apps from 2015 that their maintainers have abandoned will be unusable. JavaScript and Java don't have this problem. The best you could do would be to package some sort of dynamic recompilation engine with NaCl to translate between machine languages... but that seems a rather roundabout way of arriving at the JVM, doesn't it?

Porting one type of game to another platform means that the end result is the ported platform is a poor imitation of the original.

Ergo, any game developed for both platforms simultaneously is a poor imitation of itself ;)