Considering the complexity of this issue, perhaps it would be a good idea to create independent haskell repos to host compatible binary packages and/or an official AUR-clone for all of the current haskell packages in the AUR. You could then support the latest stable versions in the offical repos and maintain compatible packages for them in the AUR, and let users who require the latest versions use the official haskell repository and AUR-clone (or just cabal2arch) to acquire the very latest versions.
This is an interesting idea, especially if we get some tool support for that. AFAIK all "AUR builders" (yaourt, paktahn, etc) only know about AUR, so they need to be made a bit more configurable.
The official repos along with some others, such as my own, include a tarball named $repo.abs.tar.gz. This tarball contains all of the PKGBUILDs and local source files required to build the packages in the given repo from source. If someone were able to provide the aforementioned Haskell repos with these archives included, Bauerbill would already be able to build from them as it uses these archives to build from source (which was a design decision to make it more versatile than it would have been had it used the official ABS tree). If such a scheme is not possible, I would still be willing to try to implement support for an alternative scheme.
The biggest problem I see is that while GHC supports having multiple version of the same module available at the same time, pacman doesn't. That would mean that keeping a binary and an AUR version of the same package requires that they have different names. Not a big problem really, but it should be policed a bit.
The bigger problem that users *will* run into is diamond dependency issues (A uses B and C, both B and C use D but different versions). I believe that avoiding that would require a *very* strict policy on what goes into both binary repos and AUR. Too strict to follow the "Arch way", I think.
If a reasonable naming scheme is chosen and if different versions of the same package can install to different locations to avoid file conflicts, you can use "provides" without "conflicts" to satisfy such dependencies. As already mentioned, this might expose limitations with some AUR frontends, but it would be ridiculous to work around such limitations rather than expect the developers of those applications to address them. The viability of this probably depends on how many versions of each package one would have to support. If there would only be one version per ghc version, then maybe this could be included in the name, or if they are targeted at different releases of the Haskell platform then use that version in the name. It should also be possible to create a tool to manage Haskell packages (installation of specified versions, dependency resolution, etc) that could then update Pacman's local database to enable global removal of such packages with Pacman while leaving the complexities of finer management to a dedicated tool. This would necessarily add some complexity but it might lead to less complexity overall by eliminating the need to manage multiple versions of packages across the repos and the AUR. It should also provide finer control to users who need it. This way you would only need to manage the latest stable releases in the repos and the AUR and users who need something else could handle that themselves with this tool.