Hi Daniel, thanks for posting!
NCrunch's parallel execution works across multiple processes. It won't run threads in parallel within the same process. So unless your Messenger class is somehow backing onto state outside the process (i.e. the file system, registry, network), there is no risk of parallel execution causing the problems you're experiencing.
My best guess would be that these problems are sequence dependent, perhaps related to the behaviour of your custom attribute. Because NCrunch can run tests in any sequence and will call into processes multiple times (i.e. once for each batch), the overall behaviour can be much less predictable than a serial end-to-end test runner.
My suggestion would be to try and make sure that your code is assigning the correct value to Messenger.Default at the beginning at every test, and to avoid relying on clean-up code running after a test to reset this value. This is because even if the whole stack is working correctly, clean-up code still has some reliability problems. There are exceptions that can be thrown up from the O/S that cannot be caught by any test runner and this can result in edge cases that result in the clean-up code not being run. Continuous testing tends to surface these sorts of problems much more frequently due to the frequency of test execution using inconsistent sequences. It's good practice for every test to make sure that it takes responsibility for its own state at the start of its run.
Otherwise, you could probably make use of
IsolatedAttribute by applying this to the outlier tests. This would prevent sequence dependent behaviour from appearing by recycling the process involved.
