@mimol91 FYI, the lines of code you refer to have been introduced by @Tobion in the following PR: #6120. Maybe he has more context :)

It has always been like this even before #6120. Changing this would be a BC break. And I don't see how to make this easily configurable. @mimol91 can't you just redefine app_default_catch_all at the end as well, so that it is put at the end?

I just want to show simple example. Of course I could do it how you suggest, but it will require to copy more than one hundred routes. - I think it can be solved by creating some custom route loader.

Maybe just by adding an 'replace' as route option will be enough? Similar like utf-8 ? (In some future if we agree that there is more benefits to keep route position instead moving it on end set it as a default behavior?)

Sure a custom route loader can solve that. I don't know how you create the routes with annotation, yaml, php generated. But can't you identify your catch-all routes and import them last? So after you overwrote the others.

I m using dynamic loader (which dynamically read yaml files). I think it would be possible (There should be few catch-all routes). However its not the best solution, so I will try add replace option I think it should be possible to remember route positions read collection, and then 'sort' it.

What do You think about making this option available in Route? If I am the first one with such problem I guess it will not be good idea, Do you know anybody else with similar problem?

Since this issue is about i18n, and we have a PR on the topic in #26143, is there any alternative based on that PR that would allow achieving what you want @mimol91 in the end, without resorting to overriding anything?

@nicolas-grekas PR that you mention 'works' only for _locale in example which I've used it is different pattern for subdomain route

To illustrate it I will give more complex example.
Lets assume that its an 'github' clone project. Its 'global' - but has features which are enabled only for specific country. (For simplification lets assume that currently its available only in:

• United Kingdom
• France
• Poland
• Germany

Because of different features set for each of country: applications read Country env variable and loads specific config file. (For UK it will be config_uk.yaml) - which imports config.yaml (because some of parts are common - to avoid duplication its better to keep them in one place instead of splitting configuration four different config files). This same approach is with routing.

So in routing.yml (common)

repository_details:
    path:     /{repositoryId}/details
    defaults: { _controller: AppBundle:Default:index }
    methods: ['GET']
    requirements:
        repositoryId: \d+

repository_slug:
    path:     /{repositoryId}/{slug}
    defaults: { _controller: AppBundle:Default:catchAll }
    methods: ['GET']
    requirements:
        repositoryId: \d+

However only for France repository_details is changed a little

repository_details:
    path:     /{repositoryId}/détails   --Notice é instead of e
    defaults: { _controller: AppBundle:Default:index }
    methods: ['GET']
    requirements:
        repositoryId: \d+

Of course I can define all repository_details separately for each of country instead of putting them in common part.

//
It does not have to be related anyhow with countries. It can be as well used in e-commerce platform. Where clients buy an 'shop platform' to sell theirs products, - Most of the configuration will be common for all of the clients, - but some 'Premium client' can have some special requirements (for example 'clientA.shop-platform.com/contactUs' instead of 'anyOtherClient.shop-platform.com/contact-us'.

I am aware that it can be done by 'generating' from template separate routing file (using Ansible / any other tool) -so there will not be any 'common' routing.

I just was not sure why while overriding route definition new route does not keep 'previous position'.
I think possibility to define route priority (Mentioned in #26132 ) could solve this problem in nice manner

I'm closing as I think the current ongoing PRs have the potential to provide an alternative solution for this, and because changing the current logic would be a BC break anyway.