I agree to a point; to be a useful idiom, the semantics of the return value should primarily make code easier to read for humans -- while allowing for the useful flow construct which cuts corners on code length.
I don't find t / nil necessarily be the best range, though; the number of iterations that was looped, if non-zero, nil otherwise, conveys useful information that is often wanted and would presently require explicit code for defining and updating a counter variable that, could instead ideally just be there for you to capture, should you want it.
In languages where zero has boolean falsity, the unmodified iteration count would of course work even better and be more cleanly, but I think nil-or-positive-integer works better in Arc.
If getting the count was presumed to be the more common case (vs just figuring out if a loop ran through its body at all) I would argue for the count, zero or otherwise, but personal experience says you mostly want the "whether", not the "how many?", and that the latter is the occasional useful fringe case that mainly adds extra convenience.
Given that the number of iterations adds strictly more information, I can't see why that would be a bad idea. I agree that it's not normally what you would want, so the asymmetry between numbers and nil is probably worth it.
