Tabs rendering broken if non-existing item is in path

Recently I came across an obscure bug: http://drupal.org/node/179465 Basically it's caused by Statistics.module passing incorrect data in hook_menu(), namely creating a secondary tab under a non-existing parent (under some conditions). This bug itself is discussed in that other issue, and is quite simple in fact.

But the weird behavior resulting from such a simple mistake is scary - consider: A collision between Statistics and (disabled!) Tracker modules disrupts menu system so badly, that User-editing page doesn't show Profile-defined secondary tabs, making the profiles useless. And the broken tab itself is rendered nicely and works without problems! Now try to track such bugs down - luckily it took me "only" one day, but I'm seriously scared of similar things upcoming in contrib (unlucky combinations of modules disrupting other, unrelated ones). How would THAT look like, support-wise? :-(

Details: The exact machanism of above-linked bug is following (only happens with mentioned core modules until that other patch lands):
- Statistics define a tab 'user/%/track/navigation'.
- Tracker is disabled, so the parent 'user/%/track' doesn't exist.
- _menu_router_build() notice the missing parent, and "helpfully" reparent the tab to 'user/%'.
- On page request for 'user/xx/edit/category', the menu_local_tasks() function iterates through all tabs, presuming that tabs of the same level have equally-long paths:
* First secondary tabs on 'user/%/edit/***' are rendered and stored into array, with the key = number of path elements being 4.
* Then it go to parent-level and render primary tabs for 'user/%/***', whose number of path elements is generally 3, excepting the re-parented entry 'user/%/track/navigation' having 4 elements. Unluckily, that entry goes last, so the number 4 remains in variables, and is later used as array key for storing primary tabs. Thus, previously rendered secondary tabs are OVERWRITTEN by primary tabs.
* The resulting array (only one element in this case) is re-sorted to gain zero-starting keys, so primary tabs appear correctly as element #0. Secondary tabs are gone.

IMO, the menu system needs some simple sanity-check, to avoid such situations. The attached patch changes _menu_router_build() to discard broken parent-missing entries rather than re-parenting them. This prevents wrong data from entering the menu system, thus avoiding problems, and also forcing module-developer to fix the broken item (because it doesn't show up in menu unless correct). Also note, that the new code (very minimal, but still...) runs only at menu rebuild, not runtime.

Things to consider / discuss:

- Is the approach correct? Is menu entry with missing parent ALWAYS a wrong thing? Looking at http://api.drupal.org/api/group/menu/6 , I can't see whether it's ILLEGAL or only just USELESS to define menu items like 'a', 'a/b' and 'a/b/c/d' (note that 'a/b/c' is missing!)

- Can someone clarify what's the variable_set('menu_masks', $masks) all about, and whether it needs to be modified too? This one I somehow can't understand.

- Probably it would be good to have another sanity-check, to discard tab-sets with no default tab? Looking at the code, I can't imagine how exactly it might disrupt menu_local_tasks(), but I guess it might. But my knowledge of menu system is insufficient to try implementation of this part.

- Another approach might be a little bigger rewrite of menu_local_tasks(), to make it foolproof, not relying on path-lengths for array-keying, and so impossible to be fooled this way. But this means more work, and definitely goes beyond my limited knowledge of menu system. Still - might it be better for some reason?

- Any other ideas from menu-gurus, particularly possible side-effects, if that's the case... ;-)