It depends how we implement it, really. One option is to use distinct return values that the compiler understands, such as ControlFlow<T>, when processing the sugar. ControlFlow looks kind of like:
enum ControlFlow<T> {
NormalReturn(T),
EarlyBreak,
}
Basically the closure is telling you whether it returned normally (NormalReturn) or whether some "early break" was used (e.g., a continue, a break, etc). In the latter case, the intermediate stack frames would want to propagate that break up until the loop that expects to handle it. This very simple enum winds up requiring some local stack slots to track what kind of early break occurred: more elaborate versions might minimize that.
Something like this actually used to be builtin to the compiler instead of iterators, though we only supported ControlFlow<()> (and we just used bool for it). (Early return did require generating a local slot to store the return value.)
Another option is to have distinct traits, and maybe a distinct syntax, though I'd hope we can infer it.
I'm definitely interested in pursuing some improvements to our closure syntax, though I think that something like _ would be a simpler addition than trying to maximize our "Tennent's Correspondence Principle"-ness.
I agree though with @arielb1 that if we want to add implicit closure sugar we should think carefully about TCP.