Guy Bedford

For now, I've changed the error to be a Compile error per (2) above.

There is actually a benefit to doing this error late in that source phase imports can still support polyfilling the `wasm:` namespace in custom instantiations while only instance-level ESM imports...

Yes, that's a correct summary, with the same rules applying to any future builtins.

Yes, we have the possibility to hard-code a value here under the `wasm:` namespace in future, but for now this is not included, and the Node.js implementation will just follow...

I think if an override behaviour is desired, then that should be supported in the custom instantiation workflows by allowing importObj to override instead of having string builtins always take...

@annevk currently today, string builtins are never exposed to the module system and behave as implicit bindings more analogous to JS globals (`wasm:js-string` is fully removed from the public imports...

@annevk I'm unclear on how this makes `wasm:` web-observable differently to any other namespacing. Can you clarify exactly what aspect of observability is the issue here? Is it that one...

I've added a commit here to remove the `wasm:` scheme error entirely, to follow up with that change separately in a new PR to gain wider support for. @annevk please...

One way we can retain polyfillability while not making the `wasm:` scheme blanket observable is to explicitly deny only `wasm:js-strings` as the builtin import name that is reserved by compile...

@annevk as far as I'm interpreting the feedback, are you saying that the handling here that explicitly excludes the known compile time builtin string list is preferable to an approach...