BTW note that the mini-graph is actually something like a singly linked list of maps, following a scope chain, as you could have (and this is stupid code but still possible),

module foo { }
module bar { }
if (true) {
  module foo { }
  module baz { }
  module bing { import foo; import bar; }
}

hmm, I don't see why, here's an example:

module foo { }
(module { import foo; }).project()

if I might jump in, that framing feels to me like a much simpler model for fragments, in that the rest of the loader pipeline can work as it does already

effectively these are hard compilation-time resolution linkage. something like [[HardResolutions]] = [SourceTextA, SourceTextB] they can simply even be an ordered list actually

For those who arrive here and find a vast scroll backlog, littledan had a long conversation where we concluded that module blocks and module fragments could be framed in a way that makes them orthogonal to compartments, such that the order in which the proposals land isn’t coupled.

We concluded that importing a module block or fragment would not involve the loader hooks and would not introduce any module specifiers to the module graph.

This presumes that module blocks are a special case of module fragments and that fragments are named lexically. So, import x rather than import 'x'. The latter is the purview of the loader hooks. The former is the purview of a lexical binding to module x {}. Module blocks have a corresponding static module record, which itself consists of its own module block and its transitive lexically imported module blocks, but also capture the module referrer specifier and import meta.

There remain some free variables in the idea, but that I believe summarizes the consensus we arrived at.