> You realize 3 would make 1 and 2 harder or less valuable?

Yes that is why I think (1) and (2) need a new language.

> And 3 would have also prevented a gazillion 1s and 2s from being still with us?

I disagree. Most new features have been implemented as extensions that must be enabled with language pragmas. This is not the same thing as large breaking changes in the standard libraries.

Isn't constructing a new language the ultimate breaking change :-)

I don’t have a dog in this fight other than interest in ML-family langs generally and Haskell as a pervasive interest everywhere I go outside of Haskell. But...

No not really, if your language is intentionally designed to be a foundation for other languages. So many lisps are trivially host languages for other languages at their core. Even JS is at this point, with the widespread use of Babel and various bundlers. Those languages themselves are seldom very different underneath that.

Making a "language laboratory" for typed languages, (as opposed FFI with lowest common denominators like C or so-and-so untyped, garbage-collected language) is an open problem. I think it can be solved, but until it is, it's wishful thinking to pretend a multitude of similar languages doesn't result in tragic fragmentation of a small community.

TypeScript seems to be doing alright? Maybe there’s something I’m missing but TS is basically a type checker on top of everything JS compiles to, including the whole Babel universe and compiler transforms that support macros and arbitrary AST manipulation. Even its standard config offers a multitude of similar languages.

Having a type language on top of an untyped one is fine (except for perf). It's having multiple typed ones that compose well and aren't just reskins of the same basic type theory that's the harder part.

Isn't any breaking change the same as creating a new language?

There will be two similar yet different languages in use until everyone migrates to the new version. This process could happen quickly or not at all.

Yes, but there is much more likely to be tooling to migrate in the same name / same community case.

Only if Haskell stops being maintained, which I very much doubt would happen. Therefore no one is forced into the change.

No one is forced to upgrade to a newer version either.

Now, perhaps the problem in your eyes is the old version isn't being maintained. But I see the opposite: maintaining two versions indefinitely is the problem. The Haskell community is not infinitely big, nor growing fast enough, that if e.g. 1/2 went to Idris and 1/2 stayed, it wouldn't be catastrophic.

Making the changes we need to make, and then making it as easy as possible for everyone to migrate, I think is the best way.

I wish more people would realize this!

People have made languages to address these issues (including me), and even put them in critical systems, but it is very difficult to get people to sign on to a new language.