I think breaking changes are highly underratted and people only shy away from them because the tooling expectations in all languages are so rock bottom.
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.
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.
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.
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.
How about the middle ground of marking them as deprecated and not to be used in new code?
1) better structural types. For example, polymorphic extensible records and variants. These could even be the basis for all algebraic data types. Current encodings have poor syntax and poor type inference (due to non-injective type families). The need to make all records nominal types really gets in the way when dealing with structured data. Python is the main competitor here; and so we could also just use strings and maps, but we can do better.
2) a better module system. Even Miranda had a better module system than Haskell. OOP has first-class modules.
3) a better commitment to backwards compatibility. There have been controversial and breaking changes to Haskell's standard libraries that have done more harm than good. This has likely damaged industrial adoption of Haskell. For example, my employer, a prominent Haskell sponsor, is stuck on a 7-year old version.
Unfortunately the above problems are difficult to retrofit for and so I think a new language may ultimately be needed.