I see NPM compatibility as a temporary stopgap. They tried to make a hard break all at once, and then Bun made it clear that no, actually people still really want access to that existing ecosystem for now.

But new code written for Deno starts out on that better foundation without CommonJS, several different module-resolution algorithms, manual transpilation, competing linting and testing standards, etc etc. They just need to bridge the gap in the meantime, until Deno's own ecosystem gets more filled out. That's the dream anyway.

The pedigree of Deno does speak for at least something as well. Who better to address the flaws of a lasting project someone created than the creator themselves? Just from incentive alignment it’s a powerful motivator.

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)