Then you migrate. If the platform provides tools to do that, you use them. Otherwise you make a new namespace, upload the project to the new one, and edit the old one with a link to the new one and a deprecation warning. Then if you have a trusted announcement platform like a blog or Twitter, announce it there.

If it's feasible to do so, you also push updates to both namespaces for a little while during the transition.

And I think the package manager can do so much more here than current ones from a UX level.

For example, instead of having to push updates to both packages, you push updates to the new one and, because you've annotated the old one with the move, users have a somewhat seamless experience when they run their update: they'll get a little heads up about the move, explain that oldpackage eol'd at 5.4 and newpackage picked up at 6.0, and would you like me auto-update your manifest?

And/or the package manager supports a rename flow that does this for you.

Yeah, like I said, if the platform provides that kind of tooling, take advantage of it.