Intermittent wrong filter selection with overlapping route prefixes (equal order) in Spring Cloud Gateway 4.1.6

Im using Spring Cloud Gateway 4.1.6.
Routes are defined in application.properties. Two routes share the same prefix, and I’m not setting the order on the RouteDefinition.

spring.cloud.gateway.routes[0].uri=http://platform-dev.com/
spring.cloud.gateway.routes[0].predicates[0].name=Path
spring.cloud.gateway.routes[0].predicates[0].args[0]=/authentication/token/**
spring.cloud.gateway.routes[0].filters[0]=HeaderFilter
spring.cloud.gateway.routes[0].filters[1]=DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin

spring.cloud.gateway.routes[1].uri=http://platform-dev.com/
spring.cloud.gateway.routes[1].predicates[0].name=Path
spring.cloud.gateway.routes[1].predicates[0].args[0]=/authentication/**
spring.cloud.gateway.routes[1].filters[0]=TokenFilter
spring.cloud.gateway.routes[1].filters[1]=HeaderFilter
spring.cloud.gateway.routes[1].filters[2]=AuthorizationFilter
spring.cloud.gateway.routes[1].filters[3]=DedupeResponseHeader=Access-Control-Allow-Credentials Access-Control-Allow-Origin

Occasionally after server restarts, requests to endpoints like /authentication/token/getToken get the wrong filters those from the broader route (routes[1]) instead of the more specific route (routes[0]). Its rare and not easily reproducible on demand.

What I observed while debugging:

• In the PropertiesRouteDefinitionLocator constructor, GatewayProperties shows the routes in the correct order.
• Later, in CachingRouteLocator.publishRefreshEvent, the signals list is in the wrong order.
• I know routes are sorted via AnnotationAwareOrderComparator. With equal order values the relative order can be arbitrary, but I dont understand why this leads to the incorrect filters being applied only sometimes.

This looks similar to a past issue that was reported and fixed in older versions:

• https://github.com/spring-cloud/spring-cloud-gateway/pull/1661
• https://github.com/spring-cloud/spring-cloud-gateway/issues/1660

Im opening this bug because the top-to-bottom order of the application.properties file is not maintained when the order parameter is not present.

Start with PropertiesRouteDefinitionLocator and CachingRouteLocator.publishRefreshEvent, comparing the route order at construction with the later signals order. Reproduce the restart-dependent behavior using the two application.properties routes and verify that the more specific route consistently receives its intended filters. Done means the route order is deterministic when orders are equal, or the issue's ordering behavior is otherwise clearly resolved.