The backwards compatibility section of PEP 639 does, naturally, address these points. In that case, the only specified instance where the meaning changes, is that a warning is recommended to be issued upon use of the license field and license classifiers (use of them is only disallowed in metadata that contains the new license-expression field).
There is one practical instance, though, which perhaps spawns a related question: wheel and setuptools have already implemented added a License-File field based on an earlier draft of PEP 639, but the current version tweaks the semantics slightly to avoid several problems brought up on the thread and original setuptools and wheel issues (namely, not flattening the original license relative paths to avoid name clashes between licenses, and storing them in a subdir of .dist-info to avoid clutter, name clashes with other current and future files there and make it unambiguous what is a license).
This means that for metadata produced by tools that have implemented an earlier draft version of this PEP, adopting the metadata version in which the standard semantics are adopted does in effect change the meaning of the field, which the PEP does account for by explicitly requiring that both the field be present and the metadata version be the version specified in the PEP or later for anything related to it in the specification to apply, otherwise the behavior is unspecified.
Is this a good approach? Also, has this happened before? More broadly, what is our stance on tools adding additional fields not (yet) defined in the specification? I don’t see anywhere in Core Metadata that specifically addresses this.
One other related point: the Metadata-Version section of the core metadata spec states:
For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields.
This means if (say) PEP 639 was accepted before PEP 685 (which we can ensure doesn’t happen, but it could have), and the former became “v2.3” and the latter “v2.4”, that would mean that if the user didn’t specify any License-Expression or License-File fields, tools would be allowed (if not implicitly encouraged) to use a lower metadata version that doesn’t include the standardized extras format and normalization in “v2.4”. Is that something we really want to explicitly endorse? Not specifying it doesn’t stop tools from doing it, but at least it doesn’t implicitly encourage them to.