Sure.
I think this was a race condition bug.
Assume the following: current_ai.begin immediatly sets the stop_processing flag and than does a lot of cleanup work. When the now parallel running hook manages to set the stop_processing flag before the "yield return stop_processing" is called we now would have two async handlers running at the same time. This can result in anything (almost impossible to debug/test), because this API is not designed to have two handlers running at the same time. 

With this version I first let the handler finish (=> yielding false here). And when the handler returns, the code will resume from this point and check the stop_processing flag in line 1091. This should take care of the "expected" behavior.

In fact in the old version in the other case, when the handler was to slow to set the flag immediatly, the following would happen: The handler starts and we return false (which is correct), but after the handler returns we will not check the stop_processing flag (else if!) and execute the next handler, which in fact would than have the semantics described above (running in parallel with our cleanup).

Note especially this change made a lot of wierd behavior go away for me.
Hope this helps.