Having so many #ifdefs isn't by itself a major problem. Yes, it does introduce a small increase in compilation time and the size of the codebase. The real cost is the developer time: every developer has to come up with these these #ifdef clauses from scratch for every change that gets made, tailored to their specific code. As more and more get added, it becomes more and more of a confusing mess. It makes me wonder if this can be automated somehow. It would be nice to have a mechanism to alleviate this cost so that most developers downstream (provided that the code was written in a reasonable manner) only need to make a minimal effort to keep up, while still being able to write code that works for a reasonably large range of GHC versions. The burden of breaking changes right now is on the downstream developers, but perhaps there could be a way to shift most of that upstream to avoid this large duplication of effort. Haskell should be allowed to evolve, but there also needs to be a counterweight mechanism that provides stability in the face of constant changes. It would be something similar in spirit to base-compat, but I don't think a library package alone is powerful enough to solve the problem: a missing 'return' for example is not something a library can just patch in. I don't have any preference for "lots of small changes" vs "one big change": in the former, there is a lot of overhead needed to keep track of and fix these small changes; in the latter, there is a risk of introducing a rift that fragments the community (cf Python 2 vs 3). Maybe something in-between would be the best.