Finally had a chance to get back to this. Here's a new patch in response to Nick's review.
My only concern is the new _PyEval_EvalFunctionCode function. It is basically the existing PyEval_EvalCodeEx function with an extra parameter. I've turned PyEval_EvalCodeEx() into a very light wrapper around _PyEval_EvalFunctionCode(). This is how I tackled the backwards incompatibility of my previous patch. However, I am nervous about messing around with something like PyEval_EvalCodeEx().
I was toying with the idea of doing a more comprehensive refactor involving call_function, fast_function, and do_call, which seems like it would be a better fix. However, I'm even more reticent to make that scale of changes, especially on something so critical, even if it seems right to me currently.
I figured the safe thing for now would be to name the new function with a leading underscore to mark it as private.
Here are the results from my cursory check before and after my latest patch:
BEFORE
3 tests failed:
test_distutils test_packaging test_socket
[293234 refs]
real 14m40.578s
user 11m43.547s
sys 0m52.096s
AFTER
3 tests failed:
test_distutils test_packaging test_socket
[293171 refs]
real 14m33.785s
user 11m55.437s
sys 0m53.850s