I have been looking at the Cabal roadmap (tickets marked for bottom) and notice that no one has mentioned multi-versioning or compatibility classes. Maybe these are bad ideas? Multi-versioning seems highly desirable. Essentially, it allows us to have the same qualified names be provided by different packages for different packages. This is desirable in the case of package versions which really are no longer the same, like Parsec 2 and Parsec 3; it also allows for the case where more than one package specifies the same qualified name because it is obvious (like `Text.JSON` or some such). It stands to reason that the "package environment" specified in the `.cabal` file is enough to tell us which package we really need to use. However, there are problems, too. Like what if I have one package that depends on `parsec-2.1.0.1` and another that depends on `parsec-2.1.0.0`? With multi-versioning, they both compile fine but then I try to use a parser from one with a combinator defined in the other: this fails to compile because: parsec-2.1.0.1:Text.ParserCombinators.Parsec.GenParser is not the same as: parsec-2.1.0.0:Text.ParserCombinators.Parsec.GenParser So now we need compatibility classes. The first package might specify a package dependency like: ~parsec-2.1.0.1 where we take the `~` to mean "requires something compatible with". The second package specifies a similar dependency: ~parsec-2.1.0.0 Then the maintainer of Parsec specifies that 2.1.0.1 is compatible with 2.1.0.0 and we can compile the second package, the one that require 2.1.0.0, with 2.1.0.1 since they are compatible and that is all it is asking for. Then we try to use these two packages together and everything works. -- Jason Dusek