I'm convinced this is a problem worth solving and I'm fairly happy with the new proposed syntax, but I agree with Jordan's suggestion that if a call has multiple trailing closures, they should all be required to have argument labels.
The proposal says:
If labelling the first trailing closure were allowed, users would have to evaluate whether to include the label on a case by case basis, which would inevitably lead to linter and style guide rules to prohibit it.
If labeling the first trailing closure was required if there was more than one, the scope of this problem would be reduced somewhat. Furthermore, I'm not sure the fact that style guides might mandate a particular choice is sufficient motivation not to offer the choice at all. For example, many Swift style guides require or prohibit the use of trailing commas in collection literals, but I think most would agree the language shouldn't enforce a single approach. I'm not convinced the situation in this case is significantly different.
I also have some concerns about the future source break this proposal considers:
The behavior of this call can’t be changed without potentially breaking source compatibility. That might be worthwhile to do in order to enable these sorts of APIs and get more consistent type-checking behavior for trailing closures; however, it will need its own proposal, and it will only be feasible under a new source-compatibility mode. We recommend considering this for Swift 6. In the meantime, library designers will have to use overloading to get this effect instead of default arguments.
I'm hesitant to support a proposal which introduces confusing typechecking behavior and would encourage a nontrivial source break in a future version. Again, it seems like requiring the first trailing closure to be labeled would eliminate the need for a backwards scan when matching arguments. Instead, the arguments could be matched as if they were all parenthesized.