What is it actually aimed at? Is performance of native modules the main reason? Or, is it a next step of virtualization reworking?
It's an option to write critical code natively to increase your script's performance.
How will CPU consuming be counted while using native modules? And what about exception and hard-interruption points in case of CPU-, stack- or heap- overflows?
Everything remains the same, all WebAssembly manipulations are done within your regular VM environment.
Are any NATIVE <=> GAME APIs planned?
Not officially, but it's an interesting vacant area for community projects.
Alternatively, will users be able to use raw WA <=> JS APIs (memory mappings, pointers sharing etc.)?
All APIs in the
WebAssembly namespace are exposed to the user space in full.
As I remember, promises (and other async stuff) aren't handled correctly for now by game engine: is it guaranteed that native module loading will be consistent (no resets until new file will be uploaded, for example)?
Using async API is not mandatory. The example above is already changed to the synchronous instantiation.
Being a cpp developer and being faced some time ago with WA projects, I assume that WA introducing is really, REALLY hard and breaking change for run-time environment (new APIs, new bugs, new non-portabilities, suddenly new vulnerabilities -- hello native LLVM!), I just wanna wish good luck and make sure such a useful and powerful feature will be implemented with such a close attention as previous roadmap implemented features.
WebAssembly object is exposed by default on Node 8.x, so I don't think it is really that breaking.