Allow me to play devil’s advocate for a second and point out that…
“It’s the only DAW I’ve seen this happen in”
…is a strong indicator.
The problem is that all the mentioned developers have their stuff running stable and fine in countless plugin host environments, operating systems and plugin formats, most of them being far more restrictive regarding threading and general code quality than the VST world. All these devs use exactly the same UI code across all formats and operating systems, so it has to be solid from the beginning.
Maybe the wavelab team could meet up with the cubase team for an afternoon and find out what the differences really are. I mean they HAVE a working code in house (Cubase, Nuendo), it’s a bit shizophrenic to make third party devs work on this. This could be a reason why so few answered.
The closest match I’ve found regarding the reported problems is this statement from JUCE mastermind Jules saying:
"Thanks for the heads-up, but it sounds like something that’d be impossible to fix.
My guess is that Wavelab must be setting up OSX mouse-tracking areas on the window, which screws up a lot of mouse-move event handling. If that’s the case then it’s one of those “sorry, would need to be fixed in the host” bugs."
IMHO, this is exactly what is happening here. Only Wavelab mac (win seems fine), and no other plugin host on the planet seems to occasionally lock/steal (i.e. not pass through) mouse-up events. These of course are essential to the proper function of user interfaces, and sadly, fully at the control of the hosting software. One missing mouse-up will break the mouse interaction of any plugin, no matter how well they are programmed. The first layer of mouse handling of windows generated by wavelab is 100% under control of wavelab, it’s then WL’s job to pass them down to the plugin windows.
While I don’t feel great pointing my finger at wavelab, I see no other reasonable option in this specific case. But I’m open for suggestions of course.