I think that your third point (automated tooling not differentiating) is a bit flawed, and that you have missed out entirely on an entire group of people who are complaining about the changes.

To clarify, the point myself and other library/framework authors are raising is that (a) we DO have robust testing, which (b) DOES notify us of deprecations, but (c) the pace of change means we have churn every year updating our libraries to be forwards compatible with anticipated changes as indicated by said deprecations.

Yes, we could ignore these deprecations. However, there are a few issues. First, not every consumer of our libraries will disable deprection notices, which means we get reports about them. Even if you have a policy that you do not treat deprecations as error conditions that need to be resolved, you end up having to deal with the incoming issues and patches — and the average user doesn't typically search to see if something has been submitted previously. This creates work for the maintainers, as they need to close and cross-link these reports.

Second, many of the new deprecations become fatal errors when strict types is enabled. As such, having PHPUnit not convert deprecations to exceptions doesn't fix anything for libraries that enable strict types; we still end up with new failures in our code when we test against a new PHP version, which, again, leads to work.

My point is that you can have a well-maintained library that chooses to ignore deprecations and still run into churn each year as a new PHP version is rolled out.

For projects with only one or a handful of packages, this is often not terribly onerous. But for those with more (Laminas has more than 160!), it means a substantial time investment — time where we could be dealing with reported issues or adding requested features, but instead are dealing with making our code compatible with a new minor version of PHP — when minor versions are supposed to insulate us from this very sort of problem!

Don't get me wrong: I definitely approve of the majority of changes that are happening to the language. They make it more predictable, easier to work with, and allow me to write more maintainable code. But the fact that each minor release — and don't forget, minor releases are YEARLY — leads to code churn in the libraries I maintain makes me want to give up on producing OSS, because this sort of churn is busy work with very few benefits.

Do I have any ideas on how to make things easier? Not currently. Deprecations DO allow us to adapt our code earlier to upcoming language changes, and waiting 1, 2, 3, or 4 minor versions to address them would likely require far bigger, more time-consuming changes on our part later. It's the pace at which they occur that is hard on the ecosystem.

One thought I've had is to potentially accept deprecations via an RFC, but only apply them in the final minor release of the series. This would allow libraries to address them all at once, and only once every several years. However, I suspect the process to make this happen could be quite difficult/laborious on the PHP internals developers.