Is it really solved in J!3.8 as there @franz-wohlkoenig seems to suggest?

The best thing to do is to check it with the beta release :)

Honestly, I don't think I would classify anything that is a result of a user creating two menu items to point to the same content piece (the same category, the same article, etc.) as a bug that needs to be fixed. It's not a scenario that our code is going to be able to handle well, and should not be a scenario that users are creating in general. The routing code is never going to know that it needs to use a specific menu item based on context (what part of the site you're in), by design it uses the first matching menu item.

It's not so unusual to have two menuitems pointing to the same data, providing different aspect and a different amount of information, using the flexible options in menuitem configuration.

Anyway the routing code has not to know 'the context', the part of the site you're in, and choose the Itemid based on that, but I think the routing code should simply respect the Itemid, if provided!

In the scenario described above, if you navigate to 'index.php?Itemid=109' you'll have a page with two different menuitems erroneously linking to the same menuitem with Itemid=108. And that's clearly wrong.

In may opinion this is a bug to fix.
(Or alternatively you should forbid having two menuitems of the same type to the same content!)

The problem remains in J!3.8 beta2

The Itemid as given in the URL does not necessarily correspond to the Itemid that gets calculated when building URLs. If it used the one from the active URL that would mean it would have to be aware of the request context.

If when building URLs and passing raw data into the JRoute::_() function the Itemid you are specifying does not get used, then yes, THAT is a bug. So if I call JRoute::_('index.php?option=com_content&view=article&id=1&Itemid=102') and it routes to menu item ID 101, IMO that would be a bug (because the router is now overruling my specified arguments, right or wrong). But, if I call JRoute::_('index.php?option=com_content&view=article&id=1') (notice no Itemid), then rightfully so the URL should be resolved based on what the router can find in the menu tree based on that article's context.

In core, the code calling into the router generally doesn't explicitly specify the Itemid unless it is based on a parameter in that context (some of the modules have a config option for a menu item). Otherwise, it is generally left to looking things up directly from the menu trying to best match the specified arguments.

I understand.
Of course I agree, in the 2 cases you depicted.
The problem arises when Itemid is specified.
I think that if Itemid is specified it should take precedence over the rules that would build the route, eventually leading to a different Itemid.

Anyway at the moment I think this is a problem: it's possible to setup two different menuitems, that should lead to two pages, different in aspect and data shown, that really behave as the same link, leading to the same page.

A simple solution is to skip Itemid replacement if Itemid is supplied, as in the PR I submitted: #17652

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/17599

closed as having Pull Request #17652

Happy to see that now we have PR #17746 that solves this, using for MenuRules.php basically the same idea I suggested here in this issue and that I proposed to solve with PR #17652:
in libraries/src/Component/Router/Rules/MenuRules.php do not replace Itemid if Itemid is supplied !

That PR is more complete and faces other issues too. Good