Well if you don’t like to take care in what state the things are. I think I have a solution.
For the Logical stuff:
As far as I’m aware your menu have static content and positions, and you can have at max only one menu open for each menu/submenu. And you have two kind of menu item: those that do menu stuff (opening, closing menu/submenu) and the rest which change the content of the view.
if your menus are fixed (size & content - theorically even if they aren’t-) you shouldn’t have to care much about anything that your two slots (menu and submenu).
for the menu stuff, we don’t really care of the menu item that only act on view content. (Except if they also change the menu state ? for now, I assume they are not)
all the rest (animations sequences) is just an implicit consequence of you filling, emptying or switching the content of those two slots.
oops, filling, emptying, switching; to many functions !
let’s reduce that to just switching ! You just need to create two… no. Just one, using two instances of it, additionnal dummy menu-widgets (one for menu and one for submenu; dummy menu are those which are perfect: no content and instant animations ! those one being those in the slot when you start the app).
Finally just a small rule, if you need to switch the menu slot, you first ensure switching submenu slot with the submenu dummy first (even if it’s already the dummy there we don’t care, I mean cause dummy animation are instant, so instant closing+instant opening it’s still instant).
Technically all you have to do is just ensure a simple interface for your menus (opening + closing, that take care of your anims). and than using in your menu item the magical switching function (with in argument the menu to put in slot and the target slot[menu or submenu]). And of course, to avoid some glitch, you just enforce your switching function to “run once” (a simple bool, to prevent it for running while it’s already switching menus; to avoid glitchy anims if a user clic everywhere)