What's done? On the menu level, I need to write the navigation block, all else is done. I also need to convert modules -- node and user already done. All this took only a dozen hours or so, beginning with the first evening/night of DrupalCon first day ending on the train to Charleroi converting user and three meetings at DrupalCon / BarCamp.
yes, this is extremely exciting. in my testing, the menu system is the slowest part of drupal (beside parsing php code - use an opcode cache to fix). this new system gets rid of the $may_cache switch in hook_menu(). hook_menu is now called only upon module enable/disable and admin/menu. this is outstanding. however, we no longer have a place to stick our drupal_add_css() and drupal_add_js() type calls. so, lets create a new hook_signal($op) which fires at various points during a request. Initially, it replace hook_init() and hook_exit() with $op=precache, $op=postcache, and $op=exit. We shall also add $op=postbootstrap which is where the drupal_add_css calls will go. One minor complication is that we no longer have hook_init and hook_exit for determining which modules need to be bootstrapped (see system.module and the bootstrap column of system table). But we do have .install files now so my proposal is that modules which require loading during bootstrap perform an UPDATE system SET bootstrap=1 WHERE module=<foo> during their hook_install(). This hook_signal() patch should probably go in before this menu system.