As an analogy: like IP routing, where there can be overlapping routes, but there’s always an unambiguous choice (the most specific route, and perhaps some other priorities and metrics for detailed cases) for any given packet - and then the packet goes on to whatever later fate from there.
It’s in large part a question of semantics: is the routing decision based on matching some set of declarative conditions (url, method, other things) that can be hashed into a simple lookup, or is there any opportunity for dynamic routing evaluation (I can write some hook to influence the routing decision). Hooks might look like filters or guards, or they might look like extractors that help construct the destination for routing lookup, it’s all just about how these are arranged and where and when they run.
If routes aren’t going to be allowed to ‘reject and retry the next-best route’, regardless of whether we call it a match failure or a fallback after processing reject, the other classic mechanism is a kind of internal redirect: handlers manipulate the request in some way and it returns a response that doesn’t go back to the client, but resubmits the manipulated request to route again from the top, presumably to a new target.
These kinds of mechanisms can be dangerous and tricky to get right, but this is the web, and one of the dangers is that if something useful isn’t provided server-side, it will be done using 30x redirects via the client and expose more application logic to potential tampering by untrusted clients.
A clear evaluation of the use cases for this, and a clear articulation of how to use whatever inheritance/specialisation/fallback/redirect/rewrite mechanism to achieve things for users, is important.