I did (belatedly) think of one potential backward compat issue with PEP 685 (in particular, having producers write out the normalized form combined with using - instead of _ for the normalization character) to be aware of.
If a package’s metadata is produced with a PEP 685-conforming tool and an extra has a name that includes a _ (or a .), it is written out in its PEP 503-normalized form (with -). If tools consuming that metadata are not PEP 685-aware, i.e. they do not perform PEP 503 normalization on existing user inputs (e.g. a user attempting to install a package with that extra, a requirements.txt specifies it, or a dependent package requires it), then existing working requirement specifiers with the existing non-normalized name will stop working until the consuming tools are updated, or the normalized form of the extras name is specified instead.
This could be avoided by not having metadata producers write out the normalized form of the extras name to the core metadata (or mostly mitigated by choosing _ instead of - as the normalization character, given the latter is much more popular currently), but I’m not sure this is enough of a problem in practice to warrant that, since pip at least (by far the most popular tool in a position to encounter this problem) does appear to already normalize extras names, and to - as well, so either these cases already work, or they already don’t (and in practice, - and producer-side normalization may actually be less problematic for this existing case, the one which originally motivated this PEP). But I just wanted to mention that so others are aware.