Consider designing in tandem with top-level await to avoid duplicate use cases

[Jamesernator]

In the presence of top-level await we don't really require (although it's still nice sugar) to provide a fallback module.

For example we could replace the first example just with a module that has it's own logic for providing fallbacks:

// Array.prototype.flatten.js
try {
    await import("std:Array.prototype.flatten");
} catch {
    await import("./polyfill.js");
}

Now with that in mind, the alternatives concept of providing a list and letting the host pick whatever it wants to seems like a really good idea as I don't think there's a good way even with top-level await to provide alternatives like that.

I think developing in tandem with top-level await would provide a lot more value in the feature instead of focusing on features that could be solved with top-level await.

[ljharb]

Top-level await still isn’t synchronous; any builtin module (or polyfill for same) needs to be evaluated synchronously.