What WASM provides is an actual low-level bytecode for languages to target. Languages which transpile to javascript are forced to emit code which conforms to the particular limitations and peculiarities of javascript, which can be buggy and inefficient and brittle, whereas bytecode is more generic and only has to conform to a virtual or physical architecture. Bytecode is also faster, because it doesn't need to be interpreted.

No, because you are forced to map language semantics into JavaScript semantics, which is not possible for all features on the source language.

WebAssembly is supposed to eventually turn the browser into a general purpose VM, with all the necessary features to enable whatever compiler one might desire to implement.

You are assuming a compilation that results in high-level JavaScript code. As JavaScript is a Turing complete language, you can trivially compile any other programming language to target it, and we not only have done that a lot but even made it efficient using asm.js. All WASM is buying us is a more efficient encoding format that can be parsed more quickly than asm.js.

> All WASM is buying us is a more efficient encoding format that can be parsed more quickly than asm.js.

That is only the initial property. WASM is expected to get a number of new features that aren't expected to come to JS, like actual threads.

It also applies to asm.js.

Just because it runs does not mean it does so efficiently, or that 100% of the source language semantics are supported without any constraints.