I did call the idea crazy 
I don't think it's something that this proposal has to address immediately, but I'd love to see an audit of, say, the standard library and Foundation to see how close we could get with good heuristics.
Regarding called-exactly-once, I would argue that we didn't let that stop us for bridged Obj-C completion handlers; if a closure is called more than once in a yielding overload, we could just trap at runtime, I think? (And then if @called(exactlyOnce) or something like it ever happens, we can eliminate that trap door. Or we just wait a bit and see if @called(exactlyOnce) gets proposed/added, since its sibling is already in pitch and there's been some discussion about it.)
For potentially tricky error-throwing paths, I would wager that the function either being rethrows or generic with the same typed throws(E) clause would be enough to guarantee that errors could only be thrown before/during the yield (unlikely that an implementation would generically get an arbitrary E to throw after the fact). And then maybe a runtime trap for the misbehaving ones again.
But all that would depend on whether the audit shows it makes sense. Maybe I'll tilt at this sometime (depending on how this pitch evolves); if we had evidence that the heuristics could be good enough that the default could be opt-out (annotate the functions that would match the heuristic but shouldn't) instead of opt-in, then that would be a pretty powerful feature.