There's a similar issue with concurrent.futures.Future, and really, anything that stores exceptions and later raises them can get in trouble if there's a way to get the exception raised multiple times. This is rarely noticed because usually the exception isn't raised more than once. 

We need separate bpo issues for the other cases.

The fix is easy enough (separately store a traceback and raise using e.with_traceback(tb)) so I'm marking this as an easy issue.