Irit, the documentation is clear.

However, the problem is that the presence of StopIteration in the exception global during async return time causes very unexpected behavior.

If, during async return time (in the linked issue, I do this in a boost-python object destructor), I write code like this:

        try {
            boost::python::call(somefunction);
        } catch (boost::python::error_already_set e) {
            PyErr_Print();
        }

then two things go wrong:
1. The "catch" block runs even if "somefunction" did not raise, because StopIteration is already in the exception handler.
2. When PyErr_Print clears StopIteration, the currently-returning async function returns None, regardless of what it was supposed to return. I consider this to be interpreter-induced data corruption.

I'm not sure what happens if user code raises an additional exception.

Do you think this is a Python bug, or a Boost bug? I'm not familiar enough with interpreter internals to know whether or not there are other ways besides boost-python destructors to get code to run "during async return". If there are, I would definitely consider this a Python bug: PyErr_Print should not be able to corrupt interpreter/return state.