You realize that if that was "impossible" and "never happening", then absolutely no Python environment would be working ever?
> A version conflict should be reported as an installation failure, not allow you to continue.
Please don't make this mandatory.
> Pip will install Y >= 2.0 and won't care that package X is now broken.
Fine, I'll just quickly fix X and open a pull request, like I probably did a hundred times, then eventually if necessary deploy my fork with the fix meanwhile they do their maintenance release.
Should we not take the responsibility of the dependencies we use and contribute back??
> The "live at master" philosophy only works for small groups of similar output capacity. It won't work for an ecosystem as wide as Python.
I don't understand why, but I'm talking about "live at latest release", not "at master".
> Sometimes it will be necessary, such as for example a package dropping support for a feature that another one needs.
Then the package can just paste the code of the feature in their own, until a new lib does it, I remember having to do that twice in 20 years (except I didn't just "paste" it, but implemented a much smaller version).
Overall, it seems my approach produces versions of my software and software that I depend on that are compatible with all versions because you can always use an earlier version if you really want to deploy on an old python or whatnot, whereas you approach leads to broken packages, tech debt, and blaming the package manager.