As a _user_ JSPI looks neat, however as a compiler writer JSPI looks like an horrible hairball of security issues and performance gotchas to degrade generated WASM code performance.
Say you have a WASM module, straight line code that builds a stack, runs quickly because apart from overflow checks it can just truck on.
Now add this JS-Promise thing into the mix:
A: now how does a JS module handle the call into the Wasm module? classic WASM was a synchronous call, now should we change the signature of all wasm functions to async?
B: does the WASM internal calls magically become Promises and awaits (Gonna take a lot of performance out of WASM modules), if not we now have a 2 color function world that needs reconciliation.
C: If we do some magic, where the full frame is paused and stored away, what happens if another JS function then calls into the WASM module and awaits and then the first one resumes? Any stack inside the wasm-memory has now potential race conditions (and potentially security implications). Sure we could make locks on all Wasm entries but that could cause other unintended side-effects.
D: Even if all of the above are solved, there's still the low-level issues of lowlevel stack management for wasm compiled code.
Looking at the mess that is emscripten's current solution to this, I really hope that this proposal gets very well thought out and not just railroaded in because V8's compiler manages to support it because.
1: It has the potential to affect performance for all Wasm code just because people writing Qemu,etc are too lazy to properly abstract resource loading to cooperate with the Wasm model.
2: It can become a burden on the currently thriving Wasm ecosystem with multiple implementations (honestly, stuff like Wasm-GC is less disruptive even if it includes a GC).