This is a great point. The proposal as-is encourages future source breaking proposals. Let's not kick that can down the road. If we're going to break source, let's do this right.
If going prioritize source compatibility, the alternative of optionally allowing a label for the first trailing closure eliminates the need to change existing API. Instead, we would get an improvement to existing API: first where: { ... }, etc will be nicer to work with as they already exist.
We have two options that both seem far more reasonable than the accepted design. One is ideal and the other is source compatible. Neither would motivate followup proposals, particularly the source breaking followup that the current design may encourage.