This is just a special-case of the more general problem of forking() in a multi-threaded program (see #16500 and #6721).
Since fork() can occur at any time, even though your data structures are protected by locks, they can end up in an inconsistent state in the child process. There's nothing we can do about it, and it affects *every code that's not atomic*.
For example, even though your patch fixes this specific issue, you can still end up with the thread both in _active and _limbo at the same time (which shouldn't be a problem since both are cleared after fork(), but still).

OTOH, the patch is simple and safe, so it might be interesting (another maybe better approach would be to also iterate over _limbo in _after_fork()).

As for the reproduction in 3.3, you're probably having trouble to reproduce it because of the GIL change. You might want to play with sys.setswitchinterval().