Provide a formal way for one bundle of JS Modules to optionally reuse already loaded modules from another bundle

This whole proposal is vague enough in my mind that I don't know if what I'm asking for is applicable or not. I'm providing all my uncertainties, hoping that what I'm asking for will be clearer. Hopefully this isn't totally irrelevant :-)

Let's say two different packages may depend on possibly different versions of a common JS module (or is that never going to happen?). It's great that ES Modules can (normally) be able to work with different versions at the same time, due to scope isolation, and not contend with "dll hell" type issues. Packaging should honor that by default, erring on the side of caution.

But what about if the two packages aren't that particular about what version they can use (think specifying version ranges in npm dependencies)? I'm assuming that packages wouldn't be able to figure that out on the fly. So I would guess an ideal option might be manually creating a third package that contains the common dependencies. In an ideal world, that all seems fine (I guess), no issues there. And I'm also quite fine with the concept that we don't always live in an ideal world, and there will be scenarios where applications download multiple packages containing some redundancies.

But downloading is one thing. Loading redundant modules into memory is also something that would be good to minimize where possible. And there's one scenario where it's vital, and that has to do with using ES6 Symbols cross-package.

I raised the issue in the import maps proposal, thinking the issue would applicable there, but it isn't. I just wanted to basically raise the same issue here, in case it is relevant here.

I'm afraid I don't understanding the packaging proposal enough to propose anything concrete, but basically in the case of ES6 Symbols, I want to require only loading that module once, regardless of which one downloads first, but more generally, be able to specify ranges of acceptable versions, and reuse which one is loaded into memory first.

Start by reading the linked webpackage and import-maps proposals, focusing on how package dependencies and module identity are defined. Clarify whether the goal is single loading, reusable already-loaded modules, version ranges, or all three; done requires a concrete, agreed packaging mechanism rather than an open-ended proposal.