I'm not sure how a user can possibly resolve conflicts when 2 libraries are using 2 incompatible versions of some other library. Those need the versions they depend on.
You might not want multiple versions of Angular in your script bundle but multiple versions of small modules like an "extend" doesn't matter much.
But whether it's good or bad isn't really relevant, if you think that people are going to throw out the npm workflow because it doesn't fit into script type=module's semantics I think you're going to be disappointed. More likely they'll just not use script type=module (except perhaps after bundled).
Often times packages have far to narrow version constraints (usually from unnecessarily raising the lower bound), and/or a technically breaking change in a dependency doesn't actually break the depender. In these cases the user can override the version, test, and move on.
In more severe cases, like lodash 3->4, it is tough, but a user can try to downgrade the direct dependencies at the root of the paths that lead to the newer version.
The best antidote is for packages to maintain compatibility through consecutive major versions with decent deprecation rules, and for packages to update and test their dependencies upper bounds regularly.
You might not want multiple versions of Angular in your script bundle but multiple versions of small modules like an "extend" doesn't matter much.
But whether it's good or bad isn't really relevant, if you think that people are going to throw out the npm workflow because it doesn't fit into script type=module's semantics I think you're going to be disappointed. More likely they'll just not use script type=module (except perhaps after bundled).