I agree adding this as a per-target Swift setting that is not an 'unsafe flag' is important for the transition to Swift language version 6.
But I also think it's reasonable to expect if swift-tools-version is a 5.x value that the default Swift language version would be 5 (as it currently is) and that updating the swift-tools-version in the manifest to 6.0 would use Swift language version 6 as the default. (I also would be completely surprised if making a new package today compiled using Swift language version 4.2 or 4)
A developer would need to explicitly update the manifest to swift-tools-version: 6.0 to change the default, so without making that change, existing packages would continue to build using Swift language version 5. I believe that means source compatibility would be maintained for all existing packages.
Once moving to swift-tools-version: 6.0 all targets could continue to be built with Swift language version 5 using the existing package-level argument:
swiftLanguageVersions: [ .v5 ]
And then, as a target is migrated, it would add the proposed Swift setting:
swiftSettings: [ .swiftLanguageVersion(.v6) ]
And then, once fully migrated, all of these could be removed from the manifest.
I think this allows for source compatibility for existing packages and then no specification required after migration, while giving precise control using a fairly small number of manifest changes during migration.
(Unrelated to the pitch: I also wonder if it might be possible if during a transition period (maybe for the first year after 6.0 is released?) swift package init might ask interactively which language version, 5 or 6 is desired?
If 5, the swiftLanguageVersions: [ .v5 ] could be automatically added to the generated manifest.)