The following code in the VST wrapper:
#if JUCE_WINDOWS if (GetThreadPriority (GetCurrentThread()) <= THREAD_PRIORITY_NORMAL && GetThreadPriority (GetCurrentThread()) >= THREAD_PRIORITY_LOWEST) filter->setNonRealtime (true); #endif
looks very risky because, if the host for its own reasons uses threads with custom priority to do the real-tme audio rendering, the plug-in could be erroneously informed that the processing is being done "offline" instead, and it looks like a very bad thing depending on how serious are the assumptions done by the plug-in in the context of non-realtime rendering.
This scenario may look hypotetical and improbable, but unfortunately that's exactly what happens in SONAR, and that's also why I hit the issue in the first place.
The "heuristic" nature of the code, and the fact that is only targeted at windows builds, makes me guess that this change may have been useful in certain hosts that weren't informing the plug-in of non-realtime processing according to the VST protocol.
I have done some digging but it seems that this detection, in a simpler form, has been in place since at least 2008, when JUCE was still in SVN and descriptive commit messages weren't mandatory.
The only reference to this code here in the forum has been done here: http://www.juce.com/forum/topic/wrong-value-isnonrealtime-cubase-4
In my opinion, it would be better to disable this code. If not always, at least disable it by default and leave the chance to the developer to enable it with a custom #defined MACRO.