If Firefox isn't responsible for rendering the menu bar, then Firefox doesn't own the menu bar. It sounds like what you're describing is a process where Firefox tells the OS what items it wants the OS to put in the menu bar. Whether or not the app provides a new set of top-level menu entries during a window switch, it still seems to be entirely the responsibility of the OS to actually manage the rendering and respond to user interaction, including the OS keeping track of which top-level menu should be rendered as selected, and the OS should be enforcing that there's only zero or one selected menu.

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.