Okay, thanks for the info.
I'm a little leery of the alternatives framework. I've had to deal with that with java, and it's complicated because there are several implementations of java that don't get packaged consistently with each other. As in some alternatives provide X, Y, and Z, and some provide W, X, and Y, and figuring all that out has been frustrating. What your proposing probably wouldn't be as bad since the alternative Haskell packages would be coming from the same source and would presumably be exactly consistent with each other.
But, if the dynamic executable packages are working, are parallel static packages necessary?
Another issue is the experimental nature of a lot of Haskell packages: I recently had to make a lot of minor updates to my simulation because of a change in the aeson package, which is itself under fairly heavy development. We can probably link dynamically to well-established Haskell libraries with no problem, but the more experimental ones could result in the usual trap that executable foo requires the new features in libbar-5 but executable baz hasn't been updated yet and requires libbar-4 ... From what I can tell, GHC and Cabal are better at dealing with multiple coexisting versions of packages than RPM and Yum are.
Just thinking out loud here...