Of course the implementation and optimization of Swift varies between platforms. Taking advantage of kernel and other advancements on a particular OS is a given. However, this should not prevent deployment on some earlier versions of macOS.
I assume that Swift 5.8 will be deployed on Linux 20.04 and Windows 10, we won't need to ask our customers to update their Linux or Windows. But on macOS we will have to upgrade to macOS 14 and we will have to ask our customers to upgrade to macOS 14 as well.
It is desirable at some point to take a step forward at the OS level for multiple reasons. However, forcing our customers to update macOS every year to use the latest Swift features is very restrictive.
Important to note, neither Linux nor Windows are ABI-stable WRT Swift, and as consequence of that none of their system frameworks can expose Swift APIs.
swift on linux and windows is like the wild west. you have a lot of freedom, and you can evolve faster because you are a pioneer and there is not a lot of existing support infrastructure. but that is also a drawback: there is not a lot of existing support infrastructure, so you have to do most things yourself.
swift on macOS is like the settled east. you don’t have as much freedom and you basically have to wait for the surrounding society to upgrade before you can advance. but you benefit from the settled and mature ecosystem of that world.
so “very restrictive” is very much point-of-view dependent. you could also argue that the lack of existing frameworks on linux (and windows especially) is also “very restrictive” in a different way.
Let's be very clear here. There are sometimes new features in Swift releases that can only be used when running on a new OS release on Apple platforms. There are also many new features in Swift releases that do not require a new OS release. It is not all-or-nothing and never has been.
The fact that Swift features are sometimes tied to the OS on Apple platforms is a fact of life. Swift being integrated into the OS is what enables Apple platforms to provide native Swift APIs in the OS. It is also what enables Apple to use Swift internally in the implementation of the OS. If Swift had no ability to achieve these things because it insisted on layering on top of the OS, it would never have been released; it would be a toy project with no investment from the company. This language exists because it is able to be tied to the OS.
Being integrated into the OS does burden Swift development sometimes. Apple's development teams do try our best to make features available on earlier OSes, because we understand that features don't actually help you if you can't use them, and most code can't use features that only work on the latest OS. But that doesn't just happen automatically; it takes real engineering work, and that work comes with an opportunity cost because we don't actually have infinite resources. And sometimes the best trade-off is to focus on making the language better in other ways, with the understanding that eventually programmers will be able to roll their minimum target forward.
This conversation started in the context of a feature which we have been able to make work almost perfectly in back-deployment. The only restrictions are that you can't use these new types directly as generic arguments — you have to wrap them in a struct — and you can't dynamically cast to them. It is pretty easy to live within those restrictions and still make use of this feature. It took actual work to make that happen; for example, we had to figure out a way to diagnose the problematic uses so that programs didn't just fail to launch on old OSes with no explanation. It's taking ongoing work to make that happen; we actually just fixed a bug in it, where in some cases the compiler will do something that requires OS support when it doesn't technically need to. But we were happy to find a way to do it, because we knew that making this feature available to more people was going to be really valuable. So it's a little frustrating that, all of things, this is what's given rise to this all-or-nothing discussion.
The primary benefit of ABI stability is that it allows Apple to use Swift in system frameworks (e.g., UIKit or SwfitUI). Without ABI stability that wouldn't really be possible.
As a slight generalization of that, it also allows older binaries to run with newer dependencies. The Swift runtime and system frameworks like UIKit are one example, but in e.g. an internal distribution scenario, a stable ABI also allows you to update a common dependency of multiple applications, such as a helper library. Nowadays shared third-party dependencies aren’t so common on the Mac (and have never been possible on iOS), but when ABI stability comes to other platforms like Linux and Windows, they can adopt this technique.