As I have written many times elsewhere, I have several concerns with this direction, but I'll just repeat the most serious one here: unless something is done about the spelling of existential types, we will have introduced many type declarations into Swift that seem to say instances of the type have those APIs when they in fact do not. IMO that creates an unacceptable understandability/explainability barrier, particularly for new users.
I don't believe the syntaxes mentioned-but-not-proposed for “separating existential types from protocols” do enough to help clarify the situation. Since every P is declared to have a foo, it's not evident why any P or Any<P> doesn't also have a foo—that's not the way the English language or logic work—and the explanation is anything but simple.
The mentioned-but-not-proposed syntax for existential type constraints is inconsistent with what we've done for other constraints: where clauses now always appear outside of the <…>.
Given that we'll need room for constraints in the future, and the lack of constraints is the reason for the missing APIs on a bare existential of type P, I see no advantage in introducing the word “any”, and would like to use a syntax that points explicitly to the cure for the missing API: P where _.
As noted, I have raised other concerns (and suggested ways to address most), which I'm not going to repeat here, about “unlocking existentials” in past discussions. If the community wants to say, “yeah, we thought about those, and here's why we don't think they're a problem” I can accept that, but it's discouraging to see yet another pitch to “just lift the constraint already” without any of those concerns or suggestions having been explicitly addressed.