X25519-MLKEM768 value should be aliased to MLKEM768-X25519, because, while the first one is the unfortunate X25519MLKEM768 IANA group naming used in TLS, the actual order of concatenation is ML-KEM768 first, x25519 second, for FIPS reasons. I'm not aware of protocols that'd use a different concatenation order.

To ease the confusion and to accommodate that we've previously used both in two different contexts (X25519-MLKEM768 in the TLS one, MLKEM768-X25519 in the SSH one), crypto-policies should allow using either value, but indicate preference towards the MLKEM768-X25519 one.

crypto-policies has a pre-existing regex replacement mechanism that can optionally raise PolicySyntaxDeprecationWarning that we've already used to support syntax we find obsolete. With this we can replace \bX25519-MLKEM768\b with MLKEM768-X25519 and emit a warning to update custom (sub)policies accordingly. And, of course, we'd have to update our policies to the new name to cause no warnings.

The only things in the policy other than the values are keys, scopes and comments. keys and scopes belong to a curated list and cannot contain X25519-MLKEM768 as a substring. Comments do not affect the interpretation of the policy. So I think the existing regex replacement mechanism is adequate for the job at hand.

Were we to reverse this decision anytime later, it must be done on a y-stream release boundary.