Not sure if I'll do the full fix (need to check w/ my employer), but I'm doing some investigation.  Here's what I know so far:

At the Python level, the KeyboardInterrupt is being raised within _wait_for_tstate_lock, on "elif lock.acquire(block, timeout)".

Going into the C code, it looks like this goes through lock_PyThread_acquire_lock -> acquire_timed -> PyThread_acquire_lock_timed.  acquire_timed .  lock_PyThread_acquire_lock will abort the lock if it receives PY_LOCK_INTR from acquire_timed.

My best guess right now is that PyThread_acquire_lock_timed never returns PY_LOCK_INTR.  Indeed, I see this comment at the top of the NT version of that function:

    /* Fow now, intr_flag does nothing on Windows, and lock acquires are
     * uninterruptible.  */

And indeed, the thread_pthread.h implementations both have a path for returning PY_LOCK_INTR, while the thread_nt.h version does not.

...And that's where I am thus far.