Awesome! This week I started refactoring the HostResolveImportedModule and HostImportModuleDynamically host hooks, because I didn't want to go through host-defined behavior when importing module blocks/fragments (until they import external modules).

I now have a single HostLoadImportedModule hook, used both for static and dynamic imports, that "returns" an unlinked Module Record. ECMA-262 takes care of iterating through its dependencies, and it recursively calls HostLoadImportedModule to visit the whole graph (cc guybedford: this matches your intuition in https://github.com/tc39/proposal-js-module-blocks/pull/65#discussion_r912412376 !).

This is my proposed refactor: https://nicolo-ribaudo.github.io/modules-import-hooks-refactor/
If you are curious, this is how the module blocks spec looks like on top of that refactor: https://nicolo-ribaudo.github.io/modules-import-hooks-refactor/proposals/module-blocks - the updates to import() are relevant for "layer 0", because they show how to import a "module object".

I believe that the new logic closely resembles the loading logic introduced by "layer 0": we could probably just add a step tocheck to 2.d.ii of InnerModuleLoading that calls a module.[[ImportHook]] function, rather than always delegating to HostLoadImportedModule.

It would probably also help with module reflection: assuming that WebAssembly.Module will be a module source, the proposal could use HostLoadImportedModule(...).[[ModuleSource]] instead of introducing a new HostResolveModuleReflection AO. This would also guarantee that import module x from "x.wasm" and import * as ns from "x.wasm" import the same module, even if they do two different things with it (probably we could guarantee ns === await import(x)).

I would love to hear your thoughts on this 🙂

Did a quick scan over the refactor spec:

1. ContinueDynamicImport should not try to Link() / Evaluate() multiple times.
2. Should [[LoadedModules]] be added in Abstract Module Record instead of Cyclic Module Record? A non-cyclic-able module type can also have dependencies.
3. InnerModuleLoading is it a normative change? Say, today loading a module can be unordered (as I can recall)

Module block spec:

1. Why disallow import a module block from another realm? (13.3.10.1, step 6.a)
2. Looks like you're not using the building layers from the compartments? (Module and ModuleSource class)
3. IIRC we may want to hide the source of a module. Source may not always be available on some platform, like embedding JS engine. (21.6.2.1, step 2.a)

Thanks or the review!

1. Both Link() and Evaluate() are idempotent operations: calling them multiple times has no effect. They are the "public interface" of module records, and we shold use them rather than checking the [[Status]] (which is an "implementation detail" of Cyclic Module Records). It already happens that they are called multiple times:
   • ECMA-262 always calls them for non-cyclic module records, even if they have already been linked/evaluated
   • HTML always calls them even for all module records imported either with a <script> tag or with dynamic import, even if they have already been linked/evaluated
2. ECMA-262 never fiddles with the internals of non-cyclic module records, for example the .Link() and .Evaluate() implementations are only given for cyclic module records. From its point of view, that they are terminal nodes of the dependencies graph and they have to handle their own dependencies opaquely. However, it makes sense to move LoadRequestedModules to Abstract Module Record, where we have Link and Evaluate.
3. Hosts can still load dependencies in the order they want: they can continue pre-fetching them as they currently do, and make HostLoadImportedModule behave just like HostLoadResolvedModule/HostImportModuleDynamically depending on where it's called from. I don't think this refatoring is necessarily normative.

Regarding module blocks: yes, the spec still needs to be updated after the harmony discussions in the last week, I only rewrote the current state of the proposal.