Guy Bedford

This got me thinking if such a feature might be similarly useful on the JS side for a `import { weak x as y } from 'module'` which would allow...

Good points. We probably should support both `%AbstractModuleSource%` and `%AbstractModuleSource.prototype%` chains here yes. Perhaps that would mean two new attributes then? ``` [Exposed=*, Serializable, InstrinsicParent="%Error%", IntrinsicPrototypeParent="%Error.prototype%"] interface DOMException { /*...*/...

Would it be possible to directly permit intrinsic inheritance for interfaces of the form: ``` interface DOMException : %Error% { ... } interface Module : %AbstractModuleSource% { ... } ```...

Okay, so it sounds like if anything it would be a single attribute with some handling for class-like behaviours. If we restricted the attribute to only applying to JS intrinsics...

I've renamed the title of this issue to be "better error message", as the implementation seems correct, but having debugging information available as to what subsystem needs to be included...

Note also that `wasm-compose` does provide warnings for all unimplemented interfaces, so at least one of these can be known to always be the cause.

Thanks for the summary here, in terms of timelines I just want to summarize my own sense of things: * `import.now` - there is committee discussion and interest here, so...

Could we create a synthetic module wrapper here effectively like `export * from 'mod'; export const __esModule = true`?

Yes, this is disallowed. Instead write: ```json { "imports": { "#*": "./*" } } ``` If there's a strong argument to allow these my note in that comment still stands.

Explicitly supporting `null` as indicating the `ERR_PACKAGE_PATH_NOT_EXPORTED` for trailing slash matches sounds like it would be a useful feature! I'd gladly approve a Node.js PR along these lines, and it...