Lazy versus eager reflection

[guybedford]

One concern still remaining with the current refactoring model is the assumption that [[ModuleSourceObject]] is pre-populated by the module system onto the module record.

My concern here is that this object is a JS object not an internal specification object so would require the JS host to create both a JS object and internal host object representation for every single module loaded.

We could possibly:

1. Explicitly note that [[ModuleSourceObject]] should not have any observable initialization since it is an ambient object, and therefore that internal optimizations could lazily create it
2. Have [[ModuleSourceObject]] can be populated by a HostEnsureReflection hook or similar.

This also brings up some questions about realms as well - as a JS object, this object will be specific to the realm, but I suppose that is true of the abstract module record itself. I'm still not clear on how this fits into the cross-realm transfer story though.

[guybedford]

The best route for now is likely to add a specification note about observability of [[ModuleSourceObject]] population, to ensure that there is no observability and that hosts may optimize as necessary.

[guybedford]

This has been solved with the new GetModuleSource() abstract method.