(not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components)
What complicated designs do you have in mind?
I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.
And more pressure from more options doesn't follow, you only need to study if you actually want to diverge
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?
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?
So, basically what you want you want, as a user, is to bind arbitrary application actions to shortcuts and force click events in spite of what the developer has predicted or tested in their interface. I do not think this is a trivial problem to solve. The application would need to have a way to expose these actions consistently.
> What is he draws a circle instead of using a letter O? What of it?
Well, then you cannot expect the screen reader to work, for example, and you also cannot expect to do anything with this weird "shape". The developer has broken the standards and the user is helpless in this scenario.
> in spite of what the developer has predicted
The dev has "predicted" the menu by creating it in the first place? The framework just made sure that this menu is addressable by the user
> tested in their interface.
That's not a big loss, it's not like we've come to expect any serious testing of UIs anyway
> The developer has broken the standards
Yes, so? I don't understand the point relevant to this discussion. Should standards not exist if they can be broken? Should frameworks not try to make following standards easier? Should frameworks not allow user customizations if devs can find a way to break them?