Interesting!
One probem here would be that a wasm module can have global variables that are not exported. You'd need to export them so that JS on the outside can see them.
Another issue is JS has slightly different semantics than wasm, like unalignd loads and stores are different. This is usually not an issue, but it may be a source of bugs.
I am actually going to implement something very similar to this, using the approach in your last point - asyncify. The idea is with asyncify you will block when you try to call functions that are not shipped in the first download, and you then download and compile the complete module (which includes everything - that avoids the unexported globals issue, and allows for full speed of calls later) and then resume into the complete module I hope to have a prototype soon (but have several other urgent things, so it may take a little time).
- Alon