As a mechanism for supporting multiple ABIs, it doesn't really work unless you version everything else in the framework stack that depends on it, which then has combinatorial deployment and testing costs if there are multiple reasons why you might want to version various frameworks.
As a mechanism for supporting multiple implementations of the same ABI, it's absurdly coarse-grained.
Sure, but those people may welcome more changes like those if they help a language be on the best path for the next 20 years. Objective-C 2.0 was a huge change but very very welcomed by most. It is difficult to speak on behalf of other people.
We should be mindful of people that had to endure those changes and may be wanting more for the sake of the language being more consistent and fixing past mistakes (like dropping argument labels for stored closures/callbacks).
There’s a pretty obvious thing about Objective-C 2.0, though: although the name was misleading, big changes like that were rare in Objective-C.
Releasing nit-picky breaking changes in Swift every year or two probably isn’t worth the aggro, but another option would be to gather together breakages in a once-every-five?-years breaking change. Not everyone’s favourite spelling change, but a curated list along the lines of Slava’s one for, say, Swift 10.
Sure, but some are not nit picky changes and there is a difference between every year and every 10 :). Swift is very very young and fortunately/unfortunately tons of people jumped on it. Is it early to lock it down and avoid fixing some long standing issues now?
I mean, if you’re asking me, I think Swift was pushed into production a year or two too early and grew too fast for its own good. But I don’t have a time machine, so that doesn’t really matter now.
Perhaps Swift can borrow the LTS conception from Ubuntu.
Every 3~5 years release a breaking changes delivery called Swift X LTS, and publish incremental/compatible version every one year.
The LTS runtime can be deployed independently along with app bundle, updated/patched separately from apple's system update.
This really gives off a Python 2/3 split vibe. Python 2 is practically a very long LTS.
I think we all code against a lot of C APIs 
But I think this part of the language needs a more comprehensive re-think (and not just inout-to-pointer, but also string and array-to-pointer conversions). I can't even count the number of bugs I've seen around these implicit conversions, and I would argue that their ease of (mis)use makes them pass the bar for being "actively harmful".
Honest question: Does this mean Swift 6 will never arrive? Are we going to be on Swift 5.x forever?
No, that's not what that means; it's just that changes which cause a significant burden need to be carefully balanced, at the very least so that they can be adopted incrementally.
So: Breaking changes that are easy to fix, or even could be nearly 100 migrated by the IDE are still possible, and that’s how we get to the next major release?
It's something we're going to have to judge case-by-case, but the threshold for what the benefit of the change has to be is very high.
Can these types of things be corrected by adding the new form and eternally deprecating the existing API so it’s technically a nonbreaking change?
I'm with the camp of people saying to limit the number of breaking changes: Swift was near-impossible to learn (and teach) because half the articles on the web were for what is effectively a different language, and people are rarely circumspect enough to mention their Swift version.
Having a stable target and trying to restrict source-breaking changes to removing actively dangerous ("harmful") aspects (i.e. code beginners shouldn't write anyway) and making the language more consistent would ensure the language stays welcoming to beginners.
+9999 from me too
Most importantly though, this 
Apple consistently thumbs its nose at backward compatibility in favor of innovation (i.e., removal of headphone jack et al.), and every time they make one of those decisions I find that amid and despite the myriad moans from Crustys the world-over (cultural reference here), I'm in support of the decision because I'm in support of the ethos.
To avoid making a positive breaking change to Swift because developers are busy and don't have time for the maintenance is like skipping the gym because you're working late. Is it sometimes the right call? Absolutely. There are non-negotiable deadlines and only so many hours in a day, so the gym will get skipped sometimes, or even often, depending on one's current life chapter. But would skipping the gym and working late be good as a permanent life policy? Nobody would deny that we would get more work done, but... at what cost? The little nicks, scrapes, curvatures and discolorations build up over time, and with no regular exercise to wash them away they calcify. Once you're living in an atrophied, warped and ultimately mangled body, the fruits of all that youthful, late-night labor are much harder to appreciate, which should affect the upfront calculation of whether it's worth it.
I know that right now Swift is an entrepreneurially-minded youth trying to make its way in the world, and to that end it needs to skip the gym sometimes, spend some late nights, and cater to the clientele. Let's not lose sight, however, of that the only reason that that matters is that we plan to arrive at our envisioned future in which Swift is a dominant and ubiquitous language that we and the rest of the world get to use for everything. The only reason I desire that future is because of how much I enjoy the programmatic world inside of Swift. It is elegant, powerful, ergonomic, customizable - it invites and inspires the nimble developer. While we are coding, swimming in the world of Swift for work or play, our quality of life is being directly affected. Many people can't imagine why someone would subject themselves to the apparent tedium of being a programmer, but I always respond that they've likely had a false introduction to programming and that I'd be happy to let them in on my very non-tedious inner world with Swift. The minimalist beauty of Swift is the only reason that I'm willing to spend so much of my time in there, and it is the only reason, therefore, that I even want Swift to succeed, because if it were to lose its beauty in the process of taking over the world then I would end up leaving it for another language, or for another passion and profession altogether if there's no other language.
Therefore, I hope that we can find a compromise in our culture and policy whereby breaking changes can be throttled, factored, delayed, etc. to our hearts' content (or rather, to our clientele's hearts' content), but that our guiding philosophy is that breaking changes are ultimately needed, they are healthy, and they are welcomed as members of our future if not our present.
In my opinion significant breaking changes should be adopted incrementally deprecating legacy. My experience is bounded with iOS development, and what I can say is:
So, changes that can cause a significant burden should be adopted without much pain for developers.
On the other side, sometimes breaking changes are needed for language "healthy" evolution.
Today we have Java 13, but at the same time, there are many projects, written in Java 5. And there are still many projects, written in pure Objective-C. We can't force people to use new language versions.
Earlier, when Swift was not ABI stable, Swift standard library was embedded in the application binary.
In theory, we can do something like this, but for legacy Swift versions.
What about the idea of embedding legacy Swift versions to the app binary, if the language version of the project is not compatible with the system version?
We can accept python2 and python3 with major changes. If it is a revolutionary change, it should be acceptable.
I don't think stances like must accept breaking change or must not break codes are particularly useful and they should be more of a case-by-case basis.
Migrating the industry from Python 2 to Python 3 took eleven years. It’s probably not a precedent we want Swift to follow if it can be avoided.