What's interesting though is that the compatibility effort seems to be on all sides. Deno has acted somewhat like a forcing function - I think a lot of Node fol

What's interesting though is that the compatibility effort seems to be on all sides. Deno has acted somewhat like a forcing function - I think a lot of Node folk want to move away from CommonJS in general (even staying within the NPM ecosystem) & having multiple targets for modules you write has given that effort some good pushes. A simple example of this in my mind is the node: prefix added to CommonJS functions in NodeJS. This has some perf/caching advantages, which may have been the main driver, but also introducing a protocol prefix to module strings happens to improve extensibility/flexibility/compat across the ecosystem - there are transpilers that change e.g. import to require() or vice-versa, so extra context in module strings is helpful there. Deno's npm: prefix has a similar effect (it would be cool if this made it into Node someday - having control over module locator strategy at import granularity seems interesting; it would certainly make a lot of bundler hacks currently in use for things like CSS/etc. simpler)