I think you may have a poor mental model of how GUI apps work, at least on macOS. Perhaps you’re confused because the menu bar looks to be a global OS element, when in reality it’s as much the responsibility of the app as an OS where the menu bar is visually drawn inside the app window.
Even if the OS “renders” the menu or “owns the pixels”, it’s still being driven by procedural code within the app in order to create those menus. This is not some declarative spec that apps just hand off and wipe their hands of. The app “owns” the menu bar, it just uses OS libraries to help with it.
If the app code misbehaves or doesn’t follow the API contract, it’s completely possible to have bugs with the menus. For example, if an app just deadlocks, the menu bar hangs with a spinning beach ball the same as any other GUI element drawn inside a window. Switching to another app will cause the menu bar to work (because that other app is now rendering the menu bar), but it will remain frozen if you switch back to the frozen app.
Not working for your particular preferences isn’t a bug; your preferences are just wrong for the vast majority of users.
The hubris of HN posters never fails to astound me. The most niche of workflows, then wonders why regular users don’t all learn esoteric keybindings and use TUIs.
I don't know if this is aimed at me or not. I don't use this workflow; in fact I'm pretty bog-standard in many of the ways I use my computers. In any case, I don't see how expecting to be able to bring up a context menu is in any way esoteric. We're in a thread about navigating GUIs using a keyboard. On many keyboards there's literally a key dedicated to opening a context menu, and on most OSs there's a pretty standard shortcut to do it as well, which is what GP was talking about and what sibling comments discuss being added more recently in MacOS. So, again, not very esoteric.
I also don't see how trying to emphasize empathy toward users translates to hubris. But sounds like you've got a bone to pick, so keep picking I guess.
Even if the OS “renders” the menu or “owns the pixels”, it’s still being driven by procedural code within the app in order to create those menus. This is not some declarative spec that apps just hand off and wipe their hands of. The app “owns” the menu bar, it just uses OS libraries to help with it.
If the app code misbehaves or doesn’t follow the API contract, it’s completely possible to have bugs with the menus. For example, if an app just deadlocks, the menu bar hangs with a spinning beach ball the same as any other GUI element drawn inside a window. Switching to another app will cause the menu bar to work (because that other app is now rendering the menu bar), but it will remain frozen if you switch back to the frozen app.