You can do that, please make sure to link to this topic in your support ticket.
I can already tell you the answer from Steinberg, though: It is the responsibility of the plugin developer to ensure not to change levels when their plugin is bypassed.
And that is true. The concept is known to every plugin developer and almost everyone gets it right. Just a lonely outlier tries to be special.
So, don’t forget to also write to the maker of the Bettermaker.
If anyone needs some plugins to be disabled - just deactivate them. Not to bypass, but deactivate. These are two different functions. In this way, the plug-in is turned off in the host itself, instead of receiving a request from the host not to process the sound. This can be done by pressing the Alt key with the bypass button. Then the color of the plugin changes to a very dark gray (instead of a lot lighter gray when bypassed).
So when Sb is at fault you rant about them being amateur etc etc…when Bettermaker are shown to likely be at fault you find it hard to believe they got it wrong and so it must still be Steinberg’s fault 
You misunderstood me, I don’t find it unbelievable that Bettermaker might have got something wrong, I find it unbelievable that the error could manifest in such a way within Cubase. What it means is that Cubase is somehow relying on the plugin to do something to ensure that it doesn’t process audio which puts everyones projects at the mercy of anyone out there who wants to have a go at creating a VST, which is unacceptable and amateur. If Cubase says a plugin is bypassed then it must be bypassed and not process audio… end of story.
I didn’t know that… thanks will give it a try.
Still seems an unfair expectation…assuming Cubase should deal with whatever bugs are thrown at it from other developers.
well then then I’m sure we get into a much wider topic which I’m sure is already discussed widely elsewhere. For me it sounds like Bypass causing plugins to be deactivated as default behaviour would be a much safer strategy and they could just ditch relying on plugin to bypass internally which is evidently high risk.
At an absolute minimum, if Cubase requests the plugin to Bypass there has to be some sort of return message to tell Cubase whether it worked. Then Cubase either follows the return message or deactivates the plugin if it fails to answer. Presumably the only way this could have happened is if the plugin says yes Bypass state is ok, but internally it does the opposite… which I find unlikely but Bettermaker will have to answer that.
As explained earlier…deactivation of plugs is done by host so you should use this for plugs not in use (also removes their latency)… If they made deactivated the default with bypass it could cause issues with automating the bypass of the plugs due to the latency compensation switching in and out.
Is it Steinberg’s responsibility if a compressor’s ratio ends up being 3:1 instead of 4:1?
SB publishes the VST spec and it’s up to developers to follow that spec. There’s no way SB could make 100% the spec is being followed without including some pretty cumbersome requirements in the code. If we’re talking about bypass then how would Cubase know that no signal flowed through the plugin? If you include a measurement feature where Cubase now measures a signal before and after a plugin to make sure nothing changed you add a lot of processing on a large project. And if you don’t do that how would Cubase possibly know? When you say that “there has to be some sort of return message to tell Cubase whether it worked” you are still relying on the plugin to do what is right - it could report to Cubase that it worked and it could still fail.
Even checking this offline by having plugins tested by Steinberg would mean a ton of work on their end, which we would pay for.
“Bypass” probably does something different from “deactivate” for a very good reason. Lik what Grim wrote.
Maybe I’m in late but, if I understood well, I had a similar issue with some iZotope plugin on masters: I switched it off but it still was active and I had to deactivate it…