My understanding is that Swift doesn't have to resort to any blurring between lexical, syntactic, and semantic analysis. The compiler changes proposed are strictly lexical. They also prioritize preserving the meaning of existing code via the no-leading-spaces rule. A interesting discussion here could be around whether or how much this rule devalues the /.../ syntax.
IMO, this is the most compelling counter-argument to the proposed /.../ syntax.
And this, or native support for case paths, would (IMO) be the most compelling workaround.