This is an idea to investigate for Composer 2. It is somewhat related to #7643 (it might solve the same cases, but I haven't checked whether they are strictly equivalent).

The idea here is to reduce the impact of the growing number of releases per package over time, thanks to the fact that most of these releases don't change the requirements (especially for patch releases).
This would run as an optimization pass at the end of building the pool (after having collected all necessary packages), before entering the solver. This optimization would work like that:

• for each package name, collect all sets of constraints coming from other packages (we need to take both require and conflict of each package into account to build this set, and also require-dev in case of the root package. The impact of replacement rules is still to determined here)
• for each package name, reduce the available versions: if 2 versions have the same constraints (considering both require and conflict) and they match the same incoming constraints from the sets collected above, keep only the preferred version among them ("preferred" as defined by the PolicyInterface).

Note that this might not drop some of the older versions, because they would be below some of the min requirements of some constraints but not of others, so the impact of this optimization should be checked more in detail (it might help more for patch versions than for minor versions).
To help for that, a more powerful check could be added: for 2 versions, if the preferred versions among them matches a superset of incoming requirements and a subset of incoming conflicts and its requirements are a subset of requirements and its conflicts are a superset of conflicts, keep only the preferred version (i.e. keep the preferred version if we are sure that it will always be selectable when the other one is)