Where this breaks down and gets tricky I feel, though, is when you get into examples where the package maintainer makes the newest version essentially useless (but in an otherwise harmless way) in protest of some grievance. I think this is a perfectly legitimate action for a maintainer to take as long as they aren't literally installing malware or opening up security vulnerabilities. Package systems stepping in in these scenarios and "bailing out" all the companies that rely on the package by taking it over are effectively silencing the maintainer. My smell test for this is if the ISP or hosting provider wouldn't yank it, neither should the package system. Hosting providers will take down malware and illegal content, but they aren't going to do more than that, and that's how it should be imo in package systems. I think the benefit of developers' voices not being silenced vastly outweighs the humorous scrambling of a bunch of companies who failed to lock their version numbers for a few short hours. The same scramble happens all the time with real-world breaking changes anyway. If the maintainer wants to effectively yank their project, they should be allowed to do so. Otherwise you never really know if you are getting the maintainer's code, or whatever the package system decides should be the maintainer's code, which breaks the trust contract upon which package systems are built.

This is another reason it's great that a lot of languages, like Crystal for example, have adopted a decentralized model.