USE CASE:
A large (very large) single hierarchical site menu occasionally wants to put some common content (eg safety references) in the local navigation in more than one section. It's OK to jump over to the main section when that link is clicked (we don't keep the breadcrumbs or anything from the copy version) but we do want to place a menu link as if it was a child of section B. The Node edit UI doesn't support that (Unless we have multiple_node_menu) but we've always been able to set that up using the Menu admin UI.
There are architectural reasons why this is not *always* a great idea, but it is possible, clients do want to do it, and there are also good arguments for continuing to support it quietly.
What should be easy:
![]()
It's always been a bit of a hidden trick getting multiple menu items that take you to the same place. It can be *done* in menu management OK, but what context you land in when you hit the node (what the expanded parent is) could only be managed by knowing the MLIDs.
In D4 and D5, we could make multiple aliases and trick it a little. But since the url_aliases started getting collapsed to the system path, that stopped working. But once you'd jiggled them, it was stable.
In D7 and D8, there is a change. I believe it's a regression, but it was to a seldom used un-feature.
The new symptom however is easily illustrated however.
Why it's a UI WTF
^ This is pure lies. It makes no sense.
menu.inc deliberately sorts the menu_link items and chooses the first consistently. That is good design. Additionally, the *first* time a page is made, that's the home for it.
Core however, is not so smart, and inside menu_link_get_preferred() it cycles through all matches, overwriting the keys with the same path until it runs out of candidates, and the most recently added duplicate menu item wins
Which means that if a menu administrator adds a shortcut to core documents from elsewhere in the site, suddenly their section owns that content and context.
Being bounced elsewhere is not the problem, that's OK when you can expect it.
The problem is that the editors UI tells them that *this* page has *this* primary menu item ... and then takes them somewhere new and wrong.
It's really hard for an editor to see what's going wrong or how to fix it.
This behavior is not intentional, and is just an oversight in the logic inside menu_link_get_preferred().
A REALLY small one-line fix - that applies to both D8 and D7 identically, will just get the system to sort its menu path link candidates so that everyone : Menu UI, Core behavior, and user expectations are in sync once more.
