Besides that, Blink is the rendering engine, Blink != Chrome. To get Chrome, you have to add in V8, NaCL, codecs, and a bunch of other stuff.
I see the promises to which Blink commits itself as being disjoint from Chrome. After all, there are lots of Chrome-only APIs, like Chrome extensions, Chrome sync, Chrome packaged apps, etc.
All those things are not enabled for web content. They are additional things that Chrome does, but they do not change how websites are built - they do not change the toolkit of things that web content has available to it.
If you add an extension to Chrome as a user, or use Chrome's syncing, that's fine. You're modifying the browser in a way that you want. But if Chrome adds a feature to web content that is nonstandard, then it risks fragmenting the web: Some sites will use it, and they will only work in Chrome. That's what the standards process is meant to avoid.
The plan announced from fairly early in NaCl's lifecycle was that when PNaCl was ready to be "fully released", it would be enabled for all web pages. The announcement this article points to merely restates that. It does not -- contrary to the article's treatment -- announce imminent plans to "fully release" PNaCl, or state that that release will happen without standardization. It simply assumes that that is the case.
It may be true, it may not, but it certainly is incorrect to state that that is what was announced in the announcement which the article links to and bases its entire string of complaints on.
If Google only enables PNaCl on the web if/when it is on track to become an industry-accepted standard, then everything is ok from my perspective - I think you agree to that?
I don't see how I could disagree with your description of what would be okay from your perspective. I'm actually not particularly concerned one way or the other; it certainly isn't as if Google hasn't pivoted to whatever the standard solution is in the past even when they've previously embraced (and enabled-by-default) a solution that ended up failing to become the standard. If Google was trying to push developer-focussed tooling as a business model and so was invested in its proprietary solutions winning, that would be different, but AFAICT there business model around improving web performance is to enable people to do more in the browser without relying on external code for the underlying OS, and if asm.js addresses that problem its just as good for them as it would be if PNaCl did it.
Part of the incentive to fork was to avoid having to maintain support for multiple JS engines in the core project. I don't think that means that Blink requires V8 so much as that Blink's support for JS engines (compared to pre-split WebKit's) no longer includes explicit support for the engine used by Safari (whose name I can't remember) as part of the source tree, and presumably will over time be more tightly adapted to the needs of V8.
This would seem to mean it will progressively become more difficult to build a Blink-based browser using a different JS engine.