> But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation.
The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut.
<object class="GtkMenuButton">
<property name="primary">true</property>
Then, you can go into a different discussion. How does the framework guide you to the correct functionality? Does it force you to include a primary menu? Does it check that if you have at least one menu, then one should be primary? What if the developer creates an unorthodox menu by creating a simple button that opens a popup with a list of buttons?
> The developer needs to know what to do.
No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed)
> What if the developer creates an unorthodox menu
What is he draws a circle instead of using a letter O? What of it?