Our original support for declaring a Swift language version gave package authors the ability to have dual-language-mode packages. This allows you to have a package that can adopt newer Swift features will still being usable by clients on the older version of the tools. In many cases your package may have to conditionalize some code on the Swift language version the code is being compiled with in order to support being used with either language version, but I expect that many package authors are willing to do that to avoid leaving older clients behind.
If we switch to using a defined enum for each language version, that will break this feature, since a package will not be able to be compatible with older tools and also know about the newer enum value. But Ankit’s suggestion of defining enums as we know about them, and leaving a “custom” option for this use case does seem like a reasonable compromise to me. (Though we might want to workshop the name “custom”).
I’ll note that having precise compiler-enforced semantics is not as important in Package.swift as it is in your actual Swift code; in your actual Swift code, anything not caught by the compiler won’t be detected until runtime, while in Package.swift the “compile” pass is always immediately followed by running the code, so we can generate runtime issues for anything the compiler didn’t catch and present those runtime issues in every place you would have seem compile-time issues. That said, it is still important for other reasons to have a clear API.