Wrong menu tree build for nodes with same url alias but different language.

Problem/Motivation

We have a case where we would have same alias for nodes that have different language. It is required to have separate nodes because of business logic and content. As a result we have separate main menu for each language so the editors can better manage those as well however when we create English menu item for node1 using the alias and then create UK menu item for node2 using the same alias the menu item for one of the languages is always wrong as pointing to the other language. This behaviour is happening both on edit of the menu item and on cache clear.

Steps to reproduce

1. Install Drupal 10
2. Install language and content translation modules
3. Add en-gb language as custom language and leave the language detection as default from url
4. Allow Page content type to be translatable and set default language to be interface language, this step is needed in order to allow same alias for different language on node create as the check is based on the entity language but not needed on edit
5. Create node 1 with English language and '/test' as alias
6. Navigate to site-url/en-gb and create node 2 with UK language and '/test' as alias
7. Navigate to site-url/ and Go to manage main navigation menu
8. Create menu item EN using '/test' as url (assume menu item id 1)
9. Create menu item UK using '/en-gb/test' as url (assume menu item id 2)
Observe that it points to node/1 instead of node/2.
10. Navigate to site-url/en-gb/admin/structure/menu/item/2/edit so the current language is set UK, it still has the alias 'en-gb/test' and save
Observe that now it points correctly to node/2
12. Navigate to site-url/en-gb/admin/config/development/performance and clear cache
Go back to menu item 1 and see that now it points to node 2 instead of node 1.
As a result when we clear cache from EN as current language the UK menu points wrong to node 1(EN), when we clear cache from UK as current language the EN menu points wrong to node 2(UK)

This same behaviour can be reproduced even if we allow language selection for menu item (so at least when editing we are always taken to correct language) and skip that language prefix when entering the url alias however it seems to be mandatory considering how the menu tree is build.

The moment we start to use more languages the cache clear would destroy the menu structure for all languages but one.

Currently the path that happens is as follows:
1. MenuLinkContent::getPluginDefinition
2. MenuLinkContent::getUrlObject
3. ..... PathValidator::getUrlIfValidWithoutAccessCheck
at this point there is new request with the alias as path, current language being EN and path being '/en-gb/test'
4. PathValidator::getPathAttributes -> PathProcessorManager::processInbound
5. .. here first the language prefix gets removed which is kinda expected but then AliasPathProcessor::processInbound is called
6. AliasManager::getPathByAlias is called but without language code
7. ConfigurableLanguageManager::getCurrentLanguage is being called however it already has static cache that the language is EN

I tried in AliasPathProcessor::processInbound to reset the language manager however when it tries to get the current language it still fails and returns EN because the request with the path '/en-gb/test' was never added to the RequestStack.

I would expect that if I process 'en-gb/test' as path it would return node/2 and not node/1 however that is not the case.

Proposed resolution

I don't have exact solution but it seems that when creating the new request in PathValidator::getUrl that should be added in the request stack and also the language

I am not 100% sure where needs to be the correct place to fix it, should consider couple of places:
1. PathValidator::getUrl when creating the new request should make sure that dependable functionality such as language from url should work from the new request
2. AliasPathProcessor::processInbound should take the language code from the passed request but that would probably hurt performance as the language is static cached in ConfigurableLanguageManager::getCurrentLanguage so should also account for that.

Remaining tasks

User interface changes

1. Find proper place to fix this

API changes

Data model changes

Release notes snippet