Enabling and prioritising interface text language detection of account administration pages causes RouteMatch to be Null in some cases

We've found a similar issue when working with the groups module. We've created a custom group_permission_calculator service, similar to the new Access Policy API but for groups. In that service, we are trying to use the \Drupal::routeMatch()->getParameter('group_content'), and that method is returning null when accessing to group_content pages. While debuging, we've found that the call to the access check comes from the following function:

\Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin::isAdminPath

This is the problematic code:

      $route_match = $this->stackedRouteMatch->getRouteMatchFromRequest($request);
      if ($route_match && !$route_object = $route_match->getRouteObject()) {
        try {
          // Some inbound path processors make changes to the request. Make a
          // copy as we're not actually routing the request so we do not want to
          // make changes.
          $cloned_request = clone $request;
          // Process the path as an inbound path. This will remove any language
          // prefixes and other path components that inbound processing would
          // clear out, so we can attempt to load the route clearly.
          $path = $this->pathProcessorManager->processInbound(urldecode(rtrim($cloned_request->getPathInfo(), '/')), $cloned_request);
          $attributes = $this->router->match($path);

Replacing the "router" service by "router.no_access_checks" is solving the issue, and seems ok in order to check if the current route is an admin route or not. The change can provide also a beneficial side-effect in terms of performance.
I'm adding a patch with that change and linking a couple of issues that might be related.

Thanks for reporting.

So fixes should be submitted via MRs.

Also could we get a test case showing the problem.