I'm not horrified by nested loops; I was just clarifying what you meant.

Another clarification: the algorithm is separate from the implementation. I
can put back your weird hash-of-hashes code (I for one welcome our Open
Source Overlord) and will stop bickering (except to mention that the
"smoosh" complexity was already there, just in separate lines, and I pulled
it into a new, discrete, testable method)...

...but as for how long to wait, I'm honestly not sure which is better. The
use case I'm thinking of is a git pull or asset precompile or other case
where there's a clump of files arriving sequentially and then stopping to
arrive. In that case I'd like to keep waiting as long as necessary, until
all those files stop coming. Ideally (for both Guard and Rerun) there would
be only one restart, but in
https://github.com/guard/listen/pull/203#issuecomment-37158550 if we just
delay once, then maybe we're only halfway through, and there'd be another
clump of files coming right after, and we'd have to restart almost
immediately.

I get that we don't want to wait *forever* -- although in that case, which
is better, a server that never restarts or a server that restarts every
second? If the latter, what's a good value for the overall timeout? 2
seconds? 10 seconds?

I think the we want an option value that means "wait at least this long
between restarts" and we may need another value for "wait at most this long
between restarts"... and another for "wait this long before checking again"
(which is 0.1 now & I agree that one should be de minimis).

This is fun! Or is it irritating? Hard to tell.