Please consider your primary point duly noted. Unfortunately I am not the right person to engage with it.
As a part-time professional package maintainer, I'm extremely concerned about the long-term practical viability of supporting more than a handful Swift toolchain release at any given time. The more releases I'll need to support, the less time I'll have to work on literally anything else.
However, at the same time, I'd also hate to see language evolution be overly constrained by forward compatibility. I don't really see how we can generally expect older compilers to build code that uses language features from the future that they do not understand.
With that said, it would certainly be helpful if forward compatibility concerns had at least some weight in the design of the language -- as I wrote earlier, library authors should not be considered second class citizens, and I think it's neither helpful nor healthy to encourage us to reach for ad hoc solutions such as running regex replacements over our source trees. (It's already bad enough when we need to reach for such tools to solve uncommon project configuration issues.) This road will simply lead to each project using their own ad hoc & buggy equivalent of the C preprocessor, or, worse, most libraries standardizing on some supercharged version of it. (gyb is best used in strict moderation, if at all.)
The more tools we are given to deal with older toolchains, the more of them we'll be able to practically support at the same time.
Of course, for most packages, it will always remain an option to refrain from adopting new language features that can't be conditionally disabled on older toolchains. The language is backward compatible, after all! (I don't think primary associated types would be particularly affected by this, though. Wrapping a full protocol declaration is an odious task, but I don't really see why it wouldn't be technically doable in most projects. On the other hand, SE-0345 (if let shorthand) would clearly belong in this category.)
By allowing package authors to limit a feature release to clients who are on a certain toolchain version, we enable libraries to eventually adopt language features that aren't compatible with earlier compilers/build systems, without breaking compatibility with folks who are stuck using older tools. I believe this is vastly preferable to not adopting these language enhancements at all.
I do want to point out that in this particular passage, you're expecting that people who (for whatever reason) won't update one piece of critical infrastructure (the OS) will on the other hand will enthusiastically upgrade another piece of critical infrastructure (the Swift compiler). Based on my personal experience, this doesn't ring true to me at all; in fact, from what I can tell, for a large chunk of users, the stability of the language environment is likely to be just as important (or more!) than the stability of the operating system.
(Edit: evidently I wasn’t clear here — I was referring to my personal experience working as a developer prior to my current job, in the days when I still had fully working vision 
. Switching to a new compiler release (or runtime or OS) was, and afaict, remains a Big Deal to many risk averse projects. And the longer it gets put off, the riskier it gets to finally update, so projects tend to get stuck on wildly outdated tools, sometimes way past their expiration date. The point I was trying to make is that I think this sort of fracturing by inertia is inevitable, no matter what Xcode’s deployment target is — I was in fact mostly thinking about server side applications running on Linux, which are able to import the packages I happen to work on. These packages must have a strategy to reduce the maintenance burden resulting from clients who deliberately keep using ancient toolchains.)