Whilst tracking down a bug in a prviate plugin it was discovered that the bug was caused by the threads contextClassLoader being set to hudson.PluginManager$UberClassLoader.
In cases where the bug did not appear the contextClassloader was the WebAppClassLoader.

This was surprising as the code in question did not set the context classloader and was running on the Computer.threadPoolForRemoting ThreadPool.

This shows that the contextClassloader in a task submitted to this ThreadPool is not stable.

It is expected that the state of a thread run in an executor from Jenkins core is in a deterministic state. 

The threadpool should be tolerant of when ad by whom Threads are created as well as ensure state is clean/stable before running tasks.
e..g - in a way similar to the Timer threads by using like the ContextResettingExecutorService