This is already possible usign plugins or the like:
Slim::Buttons::Home::addSubMenu('BROWSE_MUSIC', $name, %params);

see BrowseDB.pm.

a built-in UI, imo would be very painful and complicated given my experience trying to deal with all the options that might be wanted on the top level, and having to deal with users adding and removing during navigation, and expecting the menus to always be up to date. What I would suggest for a built-in might be a series of checkboxes to either include or not in the existing menu.  Plugins could add, and the list would change based on the server startup conditions only. 

If at some point there was an INPUT.Tree mode, then maybe we could write a yml file to track the given menu tree and allow a UI to re-order and re-level at will.

Here is one idea...not entirely sure if it will even work, as it was conceived in the wee hours this morning while in the throws of sleep deprived heat exhaustion...

use XMLBrowser for the menu system, writing teh structure in OPML as modules are loaded.  We could leverage triode's mypicks opml editor for the settings, where users could reorder and disable items at any level (assuming the editor can do "submenus").  Disabling would comment out the item, or flag it some other way.  Starting the server would compare any new menu item (current done via addMenu) is in the existing opml, adding to default location if not found.  I suppose actions could be done via the url in each opml, or some other way to parse what play/add do based on the flags (for example: container - plays all in container, audio - plays that audio item, top level container - play random on that category)

Unfortunately, I don't kno wenough about the details of ompl, xml or rss in order to make some sort of mockup to test. It work in my head, and has the advantage of being openly viewable and editable.  I can certainly handle some support on the home menu building side, since I did the work on the current hash structure. It might even free up some memory use if we don't have to hold the entire menu system (with plugins all duplicated at top level) in memory.

*** Bug 3817 has been marked as a duplicate of this bug. ***

Dean doesn't work here any more :)

Unassigned bugs cannot have a priority.