Returning the last value is probably no harder than a hardcoded t. Most of the time you don't care for more specific than a boolean, but one of those days it might come in handy.
On the other hand, that operates differently if the last value is nil; in other words, it's a tradeoff and has different semantics. I'm personally inclined to think that a boolean might be more useful.
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.
Don't CL's and Scheme's do allow the user to specify the return value? Maybe this wouldn't necessarily be the case with each, but I think it is correct in spirit to allow the user to control the return value.
