This is largely solved on my system, with a workaround. But I think something should be done to avoid it causing problems for others.
If, either using salt or via the GUI, you make an AppVM a disposable template on the Advanced tab (or via command line) and then put start-qube into the menu, NOTHING shows up in the menu (I am presently using xfce with the intent to switch to KDE later). No apps at all, for the qube as it shows up in the Apps tab (which is supposed to start it as a disp1234 disposable). There’s no issue with a named disposable.
In order to get it to work, you have to NOT include start-qube in the menu the first time. You can go back later and add it if you really want to.
Now, it doesn’t actually make sense to have start-qube be an option for a numbered disposable; they are designed to run one command (e.g., firefox) then shut down. If there is no command (as is the case with start-qube) it probably would just shut down immediately since you gave it nothing to do.
Presently in my salt files, I am simply not adding start-qube to the menu. In that case once the qube is built, I have a good menu for it. (I have to be a bit smart about it and make sure that I still do so with other kinds of qubes including named disposables.)
So I have “solved” the problem. So why this post? Because, if adding start-qube to a numbered disposable 1) doesn’t make sense and 2) breaks the menu if you try, then the settings GUI should prevent you from trying to do this (and also command line attempts to set the menu-items qvm-feature should fail with an informative message saying start-qube isn’t allowed). Alternatively, fix it so doing so doesn’t break the menu. (Yes you end up with a useless menu item amongst the others, but that’s better than no menu items at all.) I actually prefer the first option, but the second might be easier. Right now it’s very easy for a user to burn himself and wonder why his menu is broken.