Would you want all packages you're responsible for being taken over by whomever happens to be NPM's preferred forker in the event of your getting into legal troubles? I'd be strongly against that.

This should be handled the way any other fork happens: people create forks, other people audit them for stability and choose which to update their dependencies to. This isn't up to NPM to decide.

Finding a vulnerability in core-js which would highlight it in `npm audit` and then making a fork which fixes such vulnerability is much more ideomatic imho.

It's probably a better idea for individual depending projects (all 19k of them!) to evaluate their own use of this module. They may issue new versions with new dependencies, or they may not. It's not as if this code will start killing puppies just because the maintainer is unavailable.

I would imagine a better answer is for someone else in the community with familiarity on the project to create a semi-official fork.

Perhaps a less destructive change that someone with access (Github, NPM, Microsoft, etc.) could make, is to link to the new project from the readme.

Eventually when something breaks, this could be surfaced as an `npm audit` response (Core-js is no longer maintained. Switch to core-js-fork to resolve issue xyz).

You can: https://www.npmjs.com/policies/disputes

> This process is an excellent way to: Adopt an "abandoned" package

Harder is taking control of the GitHub project where the bug tracker lives and people are used to sending patches.

Not a great precedent, is rather have them forcefully depreciate the package, eventually, suggest a few alternatives in the error log, and let the user decide.