Seems like just having a bunch of “toggle visibility” issues. The button should either create a new widget and add to the view port while removing the prior one, or depending on your setup and requirements, all the widgets could potentially be created and in the viewport at the same time and the visibility is what changes based off the button clicked. So if you click a button an inventory widget opens up, then you click a button in that inventory and it opens up a second widget that shows details about the item selected etc etc.
Sounds like a perfect job for a widget switcher. Think of it as an array of tabs where only 1 is active and visible at a time. This allows you to populate the switcher at design time and then use an int index to display the pertinent menu. No need to spawn / hide / show any other widget apart from the controlling switcher.
It also works well with cycling as you’re simply adding / subtracting 1 from the current index. So pressing left / right becomes a natural process.
It generally works well. The only downside is having a slightly larger memory footprint as all the submenus reside in the memory at all times. Can be pretty much ignored unless you’re targeting mobile.
Apart from the ease of use, the other plus side is that these are instantiated early so you do not need to worry about auto-wrapped text flickering in front of your eyes. Or forcing a layout prepass to get rid of it.