UPDATE:
This session was rejected by .. well, the email didn't tell who makes these decisions.

The decision was made around a month ago, I just did not take the time to come here yet. And anyway, why does the website not do that by itself!!

Anyway, it is ok from my point of view.
A lot of what I could have said or suggested in this session is probably obsoleted by the recent and rapid progression towards symfony, that I am not able to fully keep up with atm.

Original description

Having spent (or wasted) quite some time in the menu system, and writing some menu-related contrib modules, I want to take the chance to share some of my thoughts and experiences I had along the way.

My vision is a more modular menu + router system, but without any contrib DX regression. My vision may not match 100% with e.g. chx or others, but I hope it is useful
and inspiring.

Problem

In current D6 and D7, the "menu system" is a clumped-together mess of highly interdependent subsystems:
- The menu_router system, which can map a url path of node/123/edit to the router path of node/%node/edit, with wildcard loading, access checking, page callback, etc.
- The menu_links system, used to create and display a tree of menu links.
- The procedure to pre-fill menu_links with metadata from menu_router.
- Breadcrumbs and "active trail".
- Tabs / Local tasks

The mess is both on the code level (everything in includes/menu.inc) and on the dependency level.

On the other hand, the API does actually work quite ok from a module developer's perspective, for the most common tasks: E.g. to register an administration page with tabs, breadcrumb and entry in the administration menu, one only needs to implement one hook: hook_menu().

Goal

Make the subsystems more independent, allowing to switch off what we don't need, or to replace it with something else.

While doing that, we (I) want to keep the menu system as attractive for a module developer, as it is now, for the average case.

I would argue that we can have a much nicer system, without actually throwing away all that much. Just by putting everything in its place.

Details

Anatomy of hook_menu()

Currently, hook_menu() allows modules to register router paths with settings for access checking, wildcard loading and page callback. In addition, it allows to specify a bunch of meta information such as "title", and local task information, that is used in menu_links generation, breadcrumbs, and tabs. Besides, the path is used to determine a hierarchy of elements, e.g. admin/structure is considered a parent of admin/structure/block.

Some people have argued that having all that in one hook is wrong. The idea would be to have one hook_router(), and another system to add the metadata.

We discuss if this separation would be actually necessary and useful, or if we just lose DX for no benefit.

Breadcrumbs / trails

In D6/D7 (last time I checked), breadcrumbs are just a trail within one of the site's menus.

I will showcase that menu_links is only one of many ways for breadcrumb and trail generation.

If time allows, we can have a very brief look at Crumbs module, just as a proof-of-concept.

Tabs / Local tasks

Local tasks, in their current implementation, are baked deeply into the menu_router system. But is this actually a problem, or is it just fine as it is? What are the use cases where the current implementation is no longer sufficient?

If time allows, we might have a look at Nodeaspect module and ctools page variants, showing that the current system is actually more flexible than we think.

Menu links

We show an alternative world, where menu links are an optional component, that can be disabled losing much.

People can create their own alternatives to menu_links in contrib, which may be especially better suited for "mega dropdown menus", storing an icon with each menu item, etc.

If time allows, we might have a look at menupoly and dqx_adminmenu, showing that displayable trees menu links can be built on the fly, without a dedicated menu_links table in the database. E.g. someone could render a menu built from taxonomy entries, or directly from menu_router.

Especially, the auto-generation of menus from menu_router information should not be as essential a part of Drupal core, as it is now.

Other systems (outside of Drupal)

In recent discussions, the masochistic term of "Drupalism" has popped up quite a lot. The idea is that we are reinventing what others already did before us, and our home-grown implementation stinks, compared to what "the others" do.

The idea is mostly valid, but the consequence is sometimes a bit too easy.
Whenever we want to get rid of a Drupalism, we should ask why this Drupalism did exist in the first place, which problems it did solve, and whether the new and shiny solution that everyone else uses actually solves our problems.

Currently I don't know much about menu systems (routing + menu display) outside of Drupal. I did a few things with Zend and symfony, but this is far too little experience for a fair comparison. Maybe I can do some research until then.