Guy Bedford

> 1. Add an import attribute for the wasm builtin collections to enable: either 'all', 'none', or a list of specific ones to enable. The default if not specified would...

Amazing news, it would be great to get this landed and implemented - that seems like it will unblock this PR from landing! Remaining considerations here seem to be: 1....

> I think we should stick with the wasm: scheme for compatibility with the Wasm JS-API. Splitting them to have different names right now would be confusing. Understood, I was...

@lukewagner pointed out that this might break round-tripping invariants in that passing the exports of one module as the imports of another module would break in the case where a...

This was since landed in https://github.com/WebAssembly/esm-integration/pull/104, with the resolution for round-tripping being the ability to still retain the underlying WebAssembly.Instance instance for direct binding between WebAssembly modules and treating this...

Just did another review of the spec text and can confirm everything continues to look good to me. One minor change I'd suggest using `16.2.1.10 GetModuleNamespace ( module, deferred )`...

> I think I'd disagree with this. I think it's better to take a two-state spec enum phase than a boolean. The problem is with three states, `source` makes no...

Per the spec, this should be immutable, which should throw a `TypeError` on `Headers.prototype.set`.

I'm removing the modules agenda label here, as the discussion around this seems to be the same topic as #33460 which is still on the agenda as well.

One problem here is that `import(pathToFileURL('/path/to/[mod.js'))` will no longer work for modules previously loaded as `import './[mod.js'`. This is because `new URL('./[mod.js', absUrl)` does not perform this escaping for us,...