That workaround mentioned in the second link is interesting… although frustrating that it would have to come to that for a plugin to “just work” in those hosts
I know that Reaper, Ardour, and Mixbus provide an option within the plugin window to allow all keyboard input to be routed to the focused plugin… is this also in DAWs like Samplitude and Cubase? I think in these cases its really an idiosyncrasy of the DAW, and should be taken up with the DAW or written about in the plugin product manuals
What kind of issues are your users running into? We had to loosely define a few rules on keyboard focus to clear up some of our own UX issues. For instance, a “reset section” button in a plugin we’re working on was grabbing focus if you clicked on the window background… you can imagine how frustrating it is once a user presses space to “play” and it gets sent to that button
Since then we always define our main view to allow grabbing focus, but to not “use” or capture key presses. We also make sure that unless you specifically wanted a widget to grab focus (focusing on it with the tab key or mouse interaction) the focus falls back to this main view. It also lets you “unfocus” all widgets by clicking within the plugin background, etc.
This helps avoid confusion and makes things a bit clearer for end users, since the default behaviour then becomes: “our plugin has focus, but until you focus a specific widget we’ll just pass all the keyboard input to the DAW”.