My gut reaction is that it feels somewhat... aggressive to change the behavior of bare P in the same release where we're requiring the use of any. I think I'd prefer if we give some time for Swift 6 to 'settle', and then reintroduce the 'bare P' syntax in a future release (and since it's purely additive syntax in Swift 6.x, it could even be a minor release).
More concretely, using an example raised in your post:
Similarly, in
var value: some P = ConcreteP(), the some keyword conveys that the underlying type cannot change.
Long term (say, Swift 7 and beyond), I'm not sure it makes a ton of sense to require some P here instead of just P, even if users could more clearly document their intent by writing some. But if Swift 6.0 allows P to mean some P in this position, we'd be silently changing behavior from Swift 5.x where value had type any P, which I think is also untenable.
So that would leave the transition in a middle ground where we'd change the meaning of bare P in some circumstances but emit an error in others, only to eventually enable it everywhere. That seems... overly messy to me compared to first requiring the removal of all 'bare P' usages to transition to Swift 6, followed by the incremental introduction of the bare-P-as-some-P syntax.