Yes, we pick a deployment target (a lowest supported version of iOS/macOS/etc.) at build time, and we're then allowed to use language, standard library, and SDK

Yes, we pick a deployment target (a lowest supported version of iOS/macOS/etc.) at build time, and we're then allowed to use language, standard library, and SDK features that are supported by that deployment target. We can also conditionally use newer features when the app runs on a newer target, using @available and #available syntax. Swift 6 will not change the ABI in an incompatible way. If Swift 6 introduces features that require runtime support, then code that uses those features will not back-deploy, but other code will. We have seen this before. For example, Swift 5.7 implemented SE-0309 (“Unlock existentials for all protocols”). Some of the new features of SE-0309 required runtime support, and if you wrote code that used those features, the program would not back-deploy. But (I think) the compiler emits an error if your deployment target doesn't ship with the Swift runtime that supports those features. The big changes in Swift 6 will be new semantic restrictions related to concurrency, and possibly a small amount of breaking changes to syntax. These changes will prevent some existing Swift 5 code from compiling in Swift 6 mode. That is the reason the major version number will change.