ESM supports intra-package absolute specifiers (/top-level-dir/module.js) relative to a package root to avoid long unreadable ../../../top-level-dir/module.js chains. This is currently possible in CommonJS.

ESM supports alternative resolution when running tests in order to achieve convention-driven mocking: import './x' prefers ./x.test.js if it exists, rather than the usual ./x.js. This is currently possible in CommonJS.

@-prefixed bare-specifiers that refer to dependencies via an out-of-band manifest file (that defines the mapping similar to package-name-maps) can be loaded by Node without a build step.

If I forget to list all my dependencies in package.json, I could run my Node app in a strict asserting mode where name resolution will fail if my code accidentally imports:

• bare-specifiers not explicitly listed as dependencies (this can be achieved today for the top level project by installing dependencies with the npm option --global-style at the cost of having one layer of nesting of installed modules)
• relative-specifiers that wander into dependencies, i.e. node_modules

I can write a small sample module on a web-based JavaScript editor like JS Bin that can import modules from NPM (e.g. the unpkg use case).

I can deploy an app into production, but serve common modules like RxJs from a CDN.

I can depend on a dev build during development and a prod build in production.

Use case 23, 24, 26, 27, 29, 30, 31, 33. See also #109 for compatibility with browsers.