A central package cooldown is not really any different to individual cooldowns.

The main reason for the cooldown is so security companies can find the issues, not that unwitting victims will find them.

One problem of the central cooldown is that it restricts the choice to be able to consume a package immediately, and some people might think that a problem.

I can't help but wonder why security reviews aren't standard practice. Surely enterprises would be willing to pay for that? You get the default releases as they are today, then a second line that get a "security reviewed" certification released at most a few weeks later.

Of course the problem there is that security audits are fallible. Some issues are so subtle that they are only revealed years after they're introduced, despite them being open source and subject to potentially all the tools and eyes.

They are categorically different.

I can implement a dependency cooldown for my org and benefit from it immediately. An upload queue gets its value from being done centrally and allowing security researchers early access and the ability to coordinate.

> One problem of the central cooldown is that it restricts the choice to be able to consume a package immediately

Huh? The article specifically suggests there could be an opt-in to early releases, and that the published revisions are available (e.g. for researchers) just not distributed by default.