So I read the original post, and it really wasn't clear to me what exact changes were causing the issues; I don't think I'm alone in thinking the OP could have been a bit more explicit about the nature of the problem.  Also, at least Flippa is explicitly unmaintained (according to the first hit googling "Flippa Haskell"), and I hadn't seen mention of WASH for a year or more.  And of course, ghc-7.0 was released 2.5 years ago, ghc-7.6 is the current version, and there's been ample time for incompatibilities to accumulate.

Despite those issues I'm rather sympathetic to the OP, in part because most of these "breaking changes" aren't replacing a broken tool.  If the Functor/Applicative/Monad hierarchy were fixed it would cause a lot of breakage, and I (like many of us I'm sure) would have to update a lot of packages, but I wouldn't mind because that would be a clear improvement.  But replacing "import List" with "import Data.List"?  That's not even a problem.  Consider another breaking change, requiring newtype constructors be in scope for foreign imports.  This required a lot of code churn, especially as IIRC the CDouble constructor wasn't exported previously (for reasons of "abstraction", which I can also rant about), so of course it wouldn't have been in explicit import lists.  At least this has some marginal utility if you care about Safe Haskell.

I did a lot of work to get packages compilable with ghc-7.6 and submitted patches to probably a dozen different repos.  Aside from one exception (related to the FFI), every breaking change was either related to namespacing/import issues, or bumping versions in .cabal files (I consider the whole try/catch mess to be an import issue, although at least in that case the benefit is more obvious).  Two pragmas existed that duplicate functionality, one was deprecated in the last release and now the other one is deprecated while the first has been un-deprecated.  It's just rearranging deck chairs.  It doesn't feel like a significant improvement, and it's even harder to bill as one.

I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity.  Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems.  IMHO both have caused issues for Haskell developers and users in the recent and more distant past.  This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake.

(Unfortunately I'm not really sure what we can learn from this particular case, but maybe somebody wiser than me could point the way)