I haven't done a whole lot of menus in a state machine driven kind of design before. I keep trying to design something sensible and modern, and I keep noticing how my idea for approaching the problem are deficient. The perfect is the enemy of the good, I know, but I'm just aiming for fairly acceptable at this point. I'm going to describe what I'm designing right now, not just to stay public about things, but also because it'll help me keep it all straight.
At the moment the program tracks what state its in in a global variable called basis. basis is actually an object that links to almost everything about the program's progress for easy saving and loading later, but it tracks overall state too. Two of those states, and probably more in the future, involve menuing: the title screen, and the inventory screen. Additionally, some of the menu entries may spawn additional menus according to what's chosen: does the player want to pick up an item, or drop it, or use it, or equip it?
So we actually keep a stack of menus; if we open a submenu, we create a new Menu object and push it onto the stack. That part is fine. But the code that actually does things with menus, that is still in the state handling routine that is called every frame, and so that's got to track which submenu it's in. It seems like I should be able to design this in some better way (maybe the code for handling the menus should be part of the item itself?), and that possibility is distracting.