Shu-yu Guo

At the same time, I'll argue against myself in https://github.com/tc39/ecma262/pull/3357#issuecomment-2187093937. I want to resist a large refactoring which is likely to introduce more latent undiscovered bugs, and do the most...

I... think I see. If [[Status]] is unreliable as part of the same cycle we're currently iterating in, is that an issue for your preferred alternative fix in https://github.com/tc39/ecma262/pull/3357#issuecomment-2185397857?

> Perhaps we can do a follow-on? Yep, I think doing the most incremental fix we can in this PR and leave the refactoring for a follow-up is the most...

> For this PR for now, the fix looks good, although for a consistent model let's also set it to false inside of AsyncModuleExecutionRejected while we're at it as well...

In the last plenary we presented this spec bug fix as FYI, saying we'd merge if there're no concerns raised on the issue. It's been quite a while now, so...

Is the plan to gate this behind an experimental flag, independently of unflagging Wasm ESM integration generally? I didn't get the sense there's consensus for this from the Wasm CG.

> I'll only land this once https://github.com/WebAssembly/esm-integration/pull/104 has landed To clarify, "land this" means land it unflagged? > The Wasm CG vote was 6 for, 15 neutral and 1 against....

> I wasn't aware that there was any outstanding disagreement - do you have outstanding concerns? My concern is that this change has had the least baking time, and if...

IIUC, this PR adds Wasm support for both source phase imports (e.g. `import source foo from 'bar.wasm'`) and evaluation phase imports (e.g. `import 'bar.wasm'`). As @ajklein says in https://github.com/whatwg/html/pull/10380#issuecomment-2269980165, V8/Chromium...

Thanks, @codehag. The "we will support if standardized" is a bit entangled so let me try to disentangle that AFAIU: - Evaluation phase Wasm ESM integration is not yet standardized...