When a Custom SiteAccess\Matcher is implemented (ex: a modified version of eZ\Publish\Core\MVC\Symfony\SiteAccess\Matcher\URIElement)
eZ's bundled event listener eZ\Bundle\EzPublishCoreBundle\EventListener\SiteAccessListener#onSiteAccessMatch
does not give a chance to rewrite the "semanticPathinfo" using $siteaccess->matcher->analyseURI() since $siteaccess->matcher is null.
This leads to problems like 404 with media urls, ex: pathinfo=/fr/media/123 will keep the same "semanticPathinfo".
How come $siteaccess->matcher is null in that context, is that a normal behavior?
See:
https://github.com/ezsystems/ezpublish-kernel/blob/v2014.11.8/eZ/Bundle/EzPublishCoreBundle/EventListener/SiteAccessListener.php#L85

I'm asking since when using a core SiteAccess\Matcher, like eZ\Publish\Core\MVC\Symfony\SiteAccess\Matcher\Map\URI,
"semanticPathinfo" is indeed reworked by analyseURI(), i.e. semanticPathinfo becomes /media/123 when pathinfo=/fr/media/123
See:
https://github.com/ezsystems/ezpublish-kernel/blob/v2014.11.8/eZ/Publish/Core/MVC/Symfony/SiteAccess/Matcher/Map/URI.php#L46

Notes:
Matcher\URIElement had a bug that did not allow elementNumber to be higher than 1. Despite being fixed on jan 27 2017 by https://jira.ez.no/browse/EZP-25337,
it seems the behavior is still not as described by
https://doc.ez.no/display/EZP/Siteaccess+Matching#SiteaccessMatching-Availablematchers
(ex: fr/something will become fr/something/something).
Also we cannot use Regex\URI who got deprecated since it is not reversible.