There seems to be some absolute disconnect here. Suppose I want to make sure that the compiler only introduces features that don’t abruptly break a lot of code. (Good idea, right?). So how do I know if a feature abruptly breaks a lot of code? Well, I try to compile a lot of code! But whoops, the compiler breaks one thing in bytestring. Now, I can’t compile any code, because bytestring is broken. So how can I even begin to test if a compiler does or does not break packages if I do not have a head.hackage type thing to unstick me?
You might say, “ok, then don’t break bytestring”, which I think is what you mean when you say “can we make the compiler more resilient to accept existing code”. But – the whole point is, suppose that bytestring is the only thing that breaks, well, we’d like to at least know that, especially if we can just ship a new bytestring along the way and be done with it. But if we do not have a head.hackage, we cannot possibly know that. You might say “who cares, it cannot possibly matter the scope of breakage, any breakage at all without a full cycle is too much!” But first, we have established that some is unavoidable (such as fixing primitive types for architecture support reasons).
But more importantly, I think the process you advocate would make progress unbearably slow. It would discourage contributions to the compiler, and it would also, frankly, enrage the sizable contingent of end-users who are always clamoring for features.
Let me drag out again my haskell users quadrant (from A tick-tock release cycle for GHC by bgamari · Pull Request #34 · haskellfoundation/tech-proposals · GitHub)
Developer Maintainer
┌─────────┬─────────┐
L │ │ │
i │ │ │
b │ │ │
│ │ │
├─────────┼─────────┤
A │ │ │
p │ │ │
p │ │ │
│ │ │
└─────────┴─────────┘
This would go straight down the middle. App and Lib maintainers would of course be thrilled. They could make changes at an incredibly leisurely pace. App and Lib developers would be much less happy. The features they want and fixes to improve their experience would be terribly far away. And bear in mind that as a relatively small language that continues to grow, we really do need to promote end-user adoption, which means keeping developers happy, since the work new users getting into the language will do is definitionally new development. I am already imagining the enraged threads on the discourse explaining how Haskell is a stagnant language that refuses to fix known issues in a timely fashion for the sake of compatibility, and etc.
So again, what I want to underline is that you have very real concerns. But they must be balanced against other concerns, and to do so means having a concrete assessment of potential breakage. And at the moment, it seems to remain the case that the best way to have that is to have a solid head.hackage process which is widely used. With that, we can concretely navigate tradeoffs. Without it, we are left with only extremes which will necessarily make some group or another feel very unrepresented and unheard.
It seems to me that there is a useful community service lurking that just needs to get better understood and developed into something more broadly usable.