I agree with Erik that non-upgradeable packages should be constrained to installed in Cabal. I have this in my cabal config as well. Better error messages for this would be gravy.
> Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?).
Removing these upper bounds throws away what I consider vital information: What version of GHC was this package successfully built against? As was discussed elsewhere, perhaps base and other core packages should have fewer breaking changes instead.
> Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code.
I would be okay with this if we knew what would change up until base 5, but we don't so I think the effect would be the same as if the upper bound was dropped.
> * Some build plans that would have previously been impossible are now possible, without resorting to the nuclear option of --allow-newers.
I've seen this argument about making more builds plans possible several times and I don't get it. Yes it's great if a package still works when one of its dependencies goes through a breaking change, but the point is that the maintainer (generally) does not know this until that version is released. An upper bound gives the maintainer some time to test the new version, if it's just a matter of bumping the upper bound then this can be done really fast, if bigger changes need to be done then the lack of an upper bound wouldn't have helped since the package was broken with that version anyway. If we restrict this to the non-upgradeable packages, maintainers have time to test on a new version of GHC before the next haskell-platform release, as is the case right now.
You can probably tell that I'm -1 on this :)