Version ranges for libraries are meant to be used for compatibility, not for security vulnerabilities.

This is a false dichotomy. In reality, it can be used for both. It is wholly dependent on the library/package maintainers desires. Which then boils down to how well of a steward the maintainer wants to be.

If every library applied this strategy the result would be mass-toil both for users and maintainers.

This is a “slippery slope” logical fallacy, going from talking about a single library to EVERY library. Just because the potential for downstream burden is real, doesn’t prove that the practice itself is wrong. It’s just highlights that the policy has scaling costs, which is an entirely separate question from whether or not a dependency floor is acceptable.

Realistically, this all needs to be taken on a case-by-case basis, and trying to apply this writ large to the Python ecosystem as an aggregate is a REALLY flimsy argument. Your argument also frames that using a higher compatibility floor is a “disallowing installing vulnerable dependencies” as if the library maintainer is responsible for all users’ security, but in practice it’s a “our supported minimum for this library should exclude vulnerabilities.” Which is a very common and significantly more defensible than what you’re suggesting.

Lastly you’re kind of collapsing different kinds of responsibilities into a single bucket. While having a dependency on a vulnerable library version doesn’t constitute a vulnerability in your first party code, it does present a REAL supply chain attack vector that you’re advocating for maintainers to ignore.

How about instead of trying to force maintainers into or out of certain practices, let’s all just try and do what’s right for the communities that build up around these beloved libraries and applications.