On this point, no. The canonical location for the metadata spec is not a PEP, but is the definition on packaging.python.org. So metadata changes no longer “replace” anything, they stand alone as proposals for modifications to the canonical spec.
I’d not spotted this before, but you’re correct - PEP 639 shouldn’t be written as an incremental change from the previous PEP, but should take the approach of PEP 643:
- The PEP states the motivation and details of the change, and notes that a new metadata version will be needed to introduce the change. None of this needs to be substantially different from the existing information, it’s just a rephrasing to reflect the actual process.
- Either in parallel, or once the PEP has been accepted, a PR to the core metadata spec that implements the change needs to be submitted. Given how long this PEP has been in development, I’d suggest that creating that PR once the PEP has been finalised and accepted would make more sense - keeping a PR up to date all of this time would have been a major pain.