I see your point. But downstream can also be another word for “user” here.
A new user would probably start shouting “cabal hell!!!” when they try to build a simple webserver and the sql and the http library don’t have a valid common build plan because neither of the upstreams tested them together. It’s not likely to happen, but certainly possible if maintainers test only always the newest configuration at time of release and only accept exactly those bounds.
One other thing: The biggest reason for upstream to maintain bounds instead of downstream is that the upstream has more information. Downstream can (and nixpkgs does) run the test suite as well. But only upstream knows about breaking changes which don‘t cause build and test failures and for those bounds are really important and downstream packages need to be careful with them. If upstream only creates the bounds based on builds and tests succeeding this becomes less relevant.
I think there is reasonable agreement here. Using tests to verify and create bounds is really cool. I just want to urge everyone to not forget that giving reasonably wide bounds is important. So if you make a CI setup which creates bounds you should keep that in mind. Especially I want to argue for checking upper and lower bounds and then assume that values in between are fine, I think that’s a good enough approximation of testing everything.
If we take the “only release tested bounds thing” seriously, we couldn’t reasonably create the bounds from more than one build plan at once because of the possible combinatorial explosion of valid build plans for bounds created from just two build plans. Accepting that, making bounds generally convex seems reasonable to me.