Yes, but considering the plugins are typically installed through the plugin store, it is usually enough for us to know something is wrong and look deeper into it. Giving technical details to the user would not really help here IMO.
For developers, we are smart enough to figure it out and diagnose the real problem.
I would not ever recommend to push a plugin binary every single time and commenting out things as a way to figure out what is wrong… work smarter not harder kinda deal.
That said, it should be way more obvious from our side to developers on how to diagnose such problems.
We have in our timeline to work on plugin developer documentation during the v1.11 release candidate phase.
Sorry this is still all a bit confusing, it has been kinda the same people developing the platform also developing/porting the plugins to it. For developers that were used to LV2 and embed linux systems (like Robin aka x42) the process was quite quick and painless (but still arduous, he spent quite some time making all those midi filter modguis!)
But not everyone is used to a setup like this.
I can compare it to web development that can target mobile platforms. If one is used to develop for regular browsers, all if pretty fine - you get direct access to developer tools, logs, and can even change the HTML stuff in-place.
But when mobile platforms get in the mix (ignoring emulators here), things are much more complicated. You can no longer rely on inplace editing, logs and other things.
There is a whole setup/workflow dedicated to remote debugging over websockets that first time you try it will make you quite confused (at least it did so to me).
My point is, everything new takes time to get used to.
Also, apologies for this not being the best experience at the moment. As I said, it is something we will work on, hopefully sooner rather than later.