CC: @stmontgomery

I think you may be correct that there is an unintentional behavioral difference here compared to the ObjC / Darwin XCTest framework. It was intentional for XCTNSPredicateExpectation to call `RunLoop.current` in order to get its run loop to use, but the timing of when it obtains that run loop looks wrong. In ObjC / Darwin XCTest, it calls `RunLoop.current` while on a private queue which is the analogue of `XCTWaiter.subsystemQueue` here. But in Corelibs XCTest, it gets the current run loop at object initialization, which is not on `XCTWaiter.subsystemQueue`.

So if my reading here is correct, it may indeed be using the wrong run loop. Although if this is the case, the correct run loop may not actually be not `.main` either, but the run loop corresponding to the thread for `XCTWaiter.subsystemQueue`.

Seems like the fix would be for XCTNSPredicateExpectation to lazily populate its `runLoop` property in `didBeginWaiting()` instead of setting it during init.

@compnerd would you like to take on this fix, or want me to? I may not get to it very soon I'm afraid.

Sure, if you won't get to it soon, I may try my hand at it.

This is no longer the case, with fixes for Python 3, I am seeing 100% test coverage on Windows as well.