Dries Buytaert wrote:
1. Do we have an idea of how many non-visible menu items there are?
A simple grep MENU_CALLBACK * | wc -l provides '67' as a first pass guess.
2. You'd still need a little bit of information about the non- visible menu items. For example, for each visible menu item, you'll want to know if it has visible children that you have access to. You need that kind of information to determine whether the menu items is a leaf, or whether it can be folded/collapsed.
For my purposes, I consider those to all be visible menu items; a further enhancement could eliminate the loading of items that are collapsed, which would be even better.
By disconnecting the visible menu from the router...
1) ...the menu title and the page title no longer need to be the same.
We choose to make page titles and menu titles identical because it is considered good practice from a usability point of view. This was suggested by usability experts. By forcing them to be the same, we enforce good behavior. It's one of the things I _really_ like about the current menu system. Decoupling both is a regression, and not a step forward.
This isn't fully true in our current system, at least with tabs. But even so, this is a philosophy, and should be enforced as such. i.e, code checked into Drupal core should match this philosophy, but should we actually force other people's sites into this mold? This is especially true if a site is choosing not to use breadcrumbs (...like most sites I know). For a completely mythical example, let's say I have an information page on my site that is properly named "The hoobar splotchets from the Village of Nom". That's fine for a page title, but boy that's a long menu title. Especially if my site's design has very little space for the menu. I have no quarrel with Drupal sticking to this as a philosophy in core and the like, but I am not so keen on forcing that philosophy on other people's sites.
3) ...we make it easier to have multiple menu items go to the same place. Karoly has mentioned this several times, but I believe it is important to re-iterate, because it matters a great deal.
In the current system, you'd just create a second menu item and point it to the same callback. How would this system make it easier? Simply because you'd need to duplicate less code? It would be great if we could see an actual example of how this becomes easier.
This is incorrect for two reasons. First, your solution creates two different places with the same content. We know from SEO work that google doesn't like this, but even without that...if the URLs are different, there are other factors that make it a different place. And you can't, in the current system, have the same path in the menu tree twice. Two, even if that works, I can't, via hook_menu(), put my items in the Primary Links navigation menu.
4) ...we make it easier to control where in the hierarchy your menu item actually falls. Right now that's all very automatic based upon the path. Which is all fine, but sometimes that's not what the developer wants, but the developer has no control over it.
This, too, encourages a consistent and structured URL schema. I like it when my navigation structure and URL schema are aligned. It makes for URLs that are easy to discover and remember. I'd hate it when the navigation structure and the paths would be "out-of-sync".
Except that node/* is automatically out of the schema of wherever we might want that content to be, just to grab an easy to see example. In this case, aliasing helps this somewhat, but not completely, and pathauto isn't part of core in any case. There are a lot of contrib modules that exist to address this as an issue. But sometimes, something might simply logically go in two places, because classification isn't always as clean as we want it. This is why we have two views for the administration page now. By Task and By Module.
5) ...we'll reduce the complexity of coding for tabs. Coding for tabs doesn't make a lot of sense right now, we're fairly limited in what we can do with them vs what users expect of them.
I agree that creating tabs is somewhat cumbersome. I'd love to see an example of how you'd do tabs in the proposed system. I have a hard time imaging how it would work, and thus, why it would be better.
I haven't given this enough thought to provide a truly good answer, but ideally with a proper parenting system, you'd largely have a setting that says "This is a tab of...", and the 'default' tab wouldn't need the 2 entries it does now. And without specifying a parent theoretically it could fall back on the URL for determining what the tab's parent would be. This needs more thinking than I have time to put into it now, unfortunately.