Quick Answers
I like the general direction this proposal is going towards, but I'm hesitant on the details.
It is a long lasting problem that generates a large interest in fixing it among the community. However, I don't think the current proposal is good enough yet for a change to Swift.
Largely, yes, but not completely.
N/A
I did not participate in the review of the previous version. I read the revised proposal in full. I'm participating in the discussion of Renaming Trailing-closure Functions in the Standard Library
Detailed Review
First, questions: How would this deal with parameter ordering? Would it be ok if the trailing closures are rearranged, so long as the labels are correctly paired with the closures? What happens when there are labels by the same name?
Now, some disagreements:
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.
I'm not sold on this argument. Potential future linter and style guide rules shouldn't matter this much to the language itself. Swift allows optional semicolons, and there must be some projects somewhere that mandate semicolon at the end of every statement, but this doesn't mean Swift should enforce no semicolons when statements are on their own lines. Similarly, Swift is indifferent to indentation styles, but different linter and style guides' rules on "spaces vs. tabs" and brace-placements don't matter to the language itself.
Recall: API authors should be naming functions assuming that the argument label of the first trailing closure will be dropped. Swift users aren’t used to seeing function names and argument labels juxtaposed without parenthesis. Many find this spelling unsettling.
I'm not sold on this argument, either. The first part is based on the proposed change to the API design guide. The second part is contradictory to the nature of Swift Evolution itself. Many things in Swift today were not familiar to users before, this proposal included if accepted. Further, what's unsettling should be determined by new users' reaction, not existing users'. In contradiction to the proposal authors' argument, I believe consistency in spelling among trailing closures is more comfortable for both new and existing users. If some of them happen to find it unsettling to have a label for the first trailing closure, they have the option of dropping it.
> The existing trailing-closure feature requires special treatment of the trailing-closure argument by the type checker because of the special power of label omission: the trailing closure can be passed to a parameter that would ordinarily require an argument label. Currently, the special treatment is specific to the final argument. Because this proposal still has an unlabeled trailing-closure argument, we have to generalize that treatment to allow label omission at an intermediate argument.
Why not just get rid of the special treatment entirely? I prefer @michelf's solution. It's elegant and backward compatible.
In general, the forced omission of the first trailing closure label is practically reintroducing a problem that SE-0046 fixed in a slightly different context.
A Possible Digression
Can this proposal be extended to function declarations as well? For a default parameter value that's a large block of code, it should be very helpful to allow it to be trailing.