Regarding empty matches evaluating to !, which you mentioned in your last post, I think before ! was introduced as a first-class type, match x {} evaluated to whatever type inference told it to. Though I don't really have a way to check if that's still true now (or was back then). And yes, return's type was () before first-class ! was introduced. I recall compiler people sighing with relief when they could finally remove special handling of unreachable code that was necessary because of that.
I was referring to people being confused over whether () is a top type (which it obviously isn't). I don't even remember if you participated in that issue's thread, to be honest.
Ouch. I mean, yes, it compiles… but you're relying on for being a sugar for loop-match and on the break from the generator implicitly converting the ! return value to the other break's type. If for were a primitive construct which actually enforces that break agree with the return type of the generator (as a good abstraction should behave), it would not work. I think it's a deficiency of this desugaring that it does.
Sure you can chain Iterators with just for, you just write two loops. Of course combinators make it more convenient, but they don't interfere with the usefulness of for for iteration on its own; for still does its job even if you don't have combinators. To contrast, the break semantics from the generator proposal diminish its usefulness for returning values from the loop quite significantly.
As the cliché goes, code is written for humans to understand and only occasionally for machines to execute. When reading code, I want to think about for as a black box most of the time, without adding its desugaring to the cognitive burden of understanding it.