Native Client is completely open: the executable format is open and the source code is open. Right now Native Client is in its early stages, so it's premature to consider Native Client for standardization.
If it lives up to its promise, and Chrome is the only browser to support it, then it says more about the other browser vendors than anything.
Just because something is a standard in no way means one way or another that browsers should actually support it. For example... C# is a non-proprietary approved spec by ECMA, but you don't see that inside of a web browser.
If something is standardized and approved by the W3C or WHATWG, and no other browsers support it, then yeah, come back and we'll chat. But that's not going to happen anytime soon. Until that happens, it shouldn't be inside of a web browser and promoted as web technology.
WHATWG is a sock puppet for the browser vendors. So saying 'the browser vendors ought to support something only if WHATWG approves it' would effectively be to say that 'the browser vendors should support something only if the browser vendors collectively want to support it'. That's obviously an argument one could make, but it would be better if one started by dropping the fiction that WHATWG is some sort of neutral party or independent source of legitimacy.
In fairness, the argument you actually made is 'the browser vendors ought to support something only if WHATWG or W3C approves it', which expands to 'the browser vendors should support something only if the browser vendors collectively want to support it, or if W3C approves it'. But that leads to obvious questions. Why is W3C approval critical for technologies of which the browser vendors collectively disapprove, but of distinctly secondary importance for the technologies they collectively like? And when was the last time the browser vendors shown much sign of meekly accepting W3C-approved technologies of which they disapprove? It seems very much as if the WHATWG HTML coup was not only about adopting features which the browser vendors wanted but which W3C was slow to standardise, but also about stymieing features which the W3C approved of but which the brower vendors don't like (like RDFa, namespaces, and HTML modularisation). So setting the W3C up as an alternative gatekeeper here seems almost as cheeky as advancing the WHATWG.
The WHATWG strikes me as exactly what a standards org is supposed to be: enough vendors to form an industry consensus get together and agree to cooperate on certain things for their collective benefit. Or is that the point you were making?
WHATWG is certainly efficient at advancing the collective interests of the browser vendors. The problem arises when those interests conflict with the interests of the rest of humanity.
Yes. For example it may say that other browser vendors care about things other than x86/x86-64 and ARM (which are all Chrome cares about; it doesn't run on any other architectures).
Of course if you _want_ use of the Web to be tied to particular hardware architectures, then Chrome's push with NaCl is ok. But some people and organizations consider such ties to be a really bad idea.
Q. Is Native Client open? Is it a standard?
Native Client is completely open: the executable format is open and the source code is open. Right now Native Client is in its early stages, so it's premature to consider Native Client for standardization.
If it lives up to its promise, and Chrome is the only browser to support it, then it says more about the other browser vendors than anything.