Description
When a dependency package / PHP extension update is released and contains a breaking change, the package maintainer that depends on that package gets a lot of support requests because of the problem.
The issue can be resolved by adapting the new stuff or introducing a conflict, which can only be added in a new version.
So my suggestion here is to allow adding afterwards conflicts to already released versions, in that way package maintainers can configure this for wide range of versions and don't get a lot of support.
There are user-land approaches to handle this, like contao/conflicts: https://github.com/contao/conflicts
which works but cannot be used together with tags, so you cannot set different conflicts for different versions.
Real-world issues that could be solved easier:
Such things often happen: https://github.com/contao/conflicts/commits/main/, which would make the life of package maintainers easier.
The change to Packagist itself would be straightforward. It would let the user manage the conflicts and merge the additional conflict data with the data in composer.json. So, an actual code change would be required, as only the metadata in Packagist matters.
What do you think about such a change in Packagist?