To be honest I think that's a much bigger hack than what I originally proposed. The point of the sub/super compiler CompilerId change is that both parts can have their own version range. For example GHCJS is currently at version 0.1.0, GHC at 7.6. While currently GHCJS can only be built against HEAD, that could change in the future (we used to have a version compatible with both 7.4 and 7.6), and one could want checks like this:
impl(ghcjs >= 0.1) && impl(ghc < 7.10)
I think this could also come in handy with Roman's haskell-suite compiler flavour, which makes it easy to make customized compilers. If you make something based on GHC it would be useful to be able to specify that, so you can support packages that depend on impl(ghc) checks. With this CompilerId change, that can be implemented for the HaskellSuite flavour by just giving the user a way to specify the compiler name/version.
If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself:
There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle)
I'd be happy to send all of them a pull req. For other projects (not on hackage), I think that with some comments/Haddock the CompilerId type they can be quickly guided towards the right change (usually ignoring the field or adding Nothing)
luite