Unrelated to my previous comment, I'm also wondering if this may actually represent a behavioural difference between contextlib.ExitStack and the interpreter's own exception handling machinery.

ExitStack uses a recursive->iterative transformation for its stack unwinding (see issue 14963), and it needs to do a bit of fiddling to get the context right (see issue 19092).

While the contextlib test suite goes to great lengths to try to ensure the semantics of normal stack unwinding are preserved, that definitely doesn't currently cover this case, and I'm thinking the way it works may actually be more like the behaviour Nikolaus expected in the original post (i.e. setting the context as the stack is unwound rather than when the replacement exception is raised).