It's certainly possible, but my two cents here are that we are not in a good place if that's what it will take.
Put another way, I think the pitch is a very intriguing idea, and it would be a great thing essentially to silently swap the meaning of naked P from any P to some P if it (a) reduces churn during the transition to Swift 6; and (b) even helps to improve the performance of users' code when they're reaching for existential types now without actually requiring it—all (c) without silently causing inadvertent changes in behavior except in the cornerest of corner cases. I think I'm well convinced of (a) and (b), but like @Jumhyn I'm quite worried about (c).
If we don't have confidence that we can migrate entire swaths of code (e.g., all public APIs) without special tools to avoid silently making correct code incorrect, then we're leaning pretty heavily on best-effort heuristics for correctness.
Particularly when it comes to the type system, I think that would fall firmly on the "un-Swifty" side of the spectrum from completeness to correctness that @itaifarber described so well. Yes, there'd be nothing more unsound about the underlying type system, but we'd be basically overlaying a "guess" as to whether a naked P in Swift 5 code should become any P or some P at the level of the migration tool, effectively making the meaning of P (or, if the tool will error, the validity of using it) heuristically determined.