Versions of package dependencies can be categorised into 5 sets: D1) Versions which the maintainer has tested and found to work D2) Versions which the maintainer has not tested but expects to work D3) Versions which the maintainer has tested and found to not work D4) Versions which the maintainer has not tested but expects to not work D5) Everything else Cabal, however, only knows of 3 sets: C1) Versions which satisfy build-depends C2) Versions which satisfy build-depends with --allow-newer C3) Everything else The problem arises from the fact that the D sets to not map well onto the C sets, even after combining D1&D2 and D3&D4. Perhaps this could be solved with a new .cabal property, breaks-with. The solver will then prefer packages in this order: 1) Versions that satisfy build-depends 2) Versions that are not in breaks-with, unless a flag such as --strict-build-depends is applied This may also lead to clearer build-depends, as instead of multiple ranges with gaps to skip know broken versions, build-depends can list a single range, and breaks-with can list the bad versions.