Error behaviour details

[guybedford]

Posting a summary from the modules meeting today:

1. The current spec will not error for importing a deferred module which is already in an errored state. It might be worth making this case error early.
2. If importing a sync module that imports an async module, it is possible for that sync module to be queued for execution by the time the promise completes either by an existing or future top-level evaluation. If we think of this in the same light as (1) above, the question then is whether the sync failure should also fail the deferred import as it can be known that the failure happened before the deferred import statically completes. If the sync module was already queued for execution we can directly attach to its completion. But if the sync module is only queued for execution later that case would be harder to track, since deferred attachments statically skip their direct sync graph components. An approach to this might be possible in the async fulfillment handlers to perform defer rejection when a defer parent "happens to be found".

In discussion we felt that (1) and (2) might be worth handling. Writing it up now I'm wondering if we should only consider (1) due to the complexity of (2), although it could be possible.

Further to the above, there is also the question of whether deferred namespaces should throw for every access or not when the module is in an errored state. There was tentative agreement on only the executor call being the one to throw.

[guybedford]

@nicolo-ribaudo happy to review any further PRs along these lines. Alternatively I'd be happy to propose some spec text if that would help, both for (1) and (2), just let me know what works best.