Have you considered a race condition at the fixture level? The PyScopeTest is not thread safe, in general. It is set up to have a single private PyScope at the class level that is created/disposed during SetUp/Dispose, and referenced in each test. However, tests within the fixture can, and do, run in parallel.
So, ps can be modified mid-test for any test in this fixture. TestThread is one of the longer tests in the fixture, so one might expect it to be more vulnerable to the data races expected of a shared state variable being replaced.
Have you considered setting either setting NonParallelizable on all of the tests in the fixture, or making the fixture itself threadsafe by making each test create its own, locally scoped, PyScope?

edit: Correction, TestThread is the only test in this fixture that exits & reenters the GIL. So, it is the only one that can possibly see ps being mutated mid-test.

However, tests within the fixture can, and do, run in parallel.

@ddneilson , can you point to the relevant documentation. AFAIK, by default NUnit runs all tests sequentially.

From https://github.com/nunit/docs/wiki/Framework-Parallel-Test-Execution :

By default, no parallel execution takes place. Attributes are used to indicate which tests may run in parallel and how they relate to other tests.

@lostmsu Interesting. We had seen this test fail as well, and traced our problem down to the fixture not being thread-safe; we were seeing the shared PyScope being mutated. Didn't realize that the tests were intended to be run in serial.