Is this a plausible scenario, though? The reason SE-0346 promised source compatibility to adopters of primary associated types was to allow the stdlib to declare that, eg, Sequence.Element was primary. This was useful because of course Sequence predated the introduction of primary associated types.
Now that the feature exists, it’s probably not as common for someone to decide an existing protocol ought to have a primary associated type after the fact, especially not a new protocol introduced after SE-0346, like your hypothetical protocol from the year 2030.
If this ever became an issue, Kavon’s feature could be generalized further to explicitly state the defaulted associated types in the event this list differs from the list of primary associated types.
What if be more concerned about is if someone had a plausible example of a protocol where the list of primary associated types differed from those that ought to default to Copyable and Escapable within an extension.