Yup, you got it; the migration/reclaiming of package names is pretty key here.
One tricky aspect of the 'metapackage' approach (where, for example, hypothetical 'lodash-legacy' or 'lodash-ng' packages could both fulfil a 'lodash' dependency slot) is that someone needs to be responsible for determining which packages can fill which slots.
In cases where the package alternatives are close forks and API-compatible, that's easier to agree on - but in a large ecosystem, the solution needs to scale in terms of human and machine review time, while also providing a good level of trust to developers when they are selecting or migrating dependencies.
There are likely to be some tricks to reduce the assessment workload required in each case -- running test suites from the 'original' package and applications which rely on it against each candidate, for example -- but ultimately either the package maintainers, the community, the NPM organization themselves -- or some mix of all of the above -- have to determine the packages that could fulfil each slot.
Good packaging is hard, and it's maintenance work rather than green-field development. We (collectively) really should incentivize and fund it more, and ideally learn from and credit existing solutions.
I'm sure there are people who enjoy reviewing (and automating review of) packages, knowing that they're improving code quality and performance for huge numbers of developers. And similarly, there are plenty of developers who provide useful feedback on package quality by reporting bugs, running benchmarks and writing qualitative comparisons.
To guess at where we may be heading in the near-term: a pure Microsoft-subsidiary ecosystem is developing in this area -- GitHub and NPM provide all the data and infrastructure to host, scan and gather user feedback for the processes mentioned above.
I think they'll collectively do a good job, although any approach does take time to build and deploy. I imagine it'll also raise longer-term questions around the governance of open source software development and what role Microsoft would like to take in that.
On a more abstract level the problem space relates to network effects and influence goals. Microsoft believes that the open source developer community is either here to stay, or is here at least for a sufficient duration of time for them to be important -- and it would like to provide influence and guide rails to that community.