New routing selection mechanism makes writing custom routing conventions harder

The documentation for writing custom OData routing conventions for ASP.NET (not Core), shows that you override SelectAction in which you examine a given route and return the controller action to execute. As outlined in Routing in ASP.NET Core OData 8.0 Preview the SelectAction method is gone and one must now implement IODataControllerActionConvention and its AppliesToController and AppliesToAction methods. These methods, instead of asking what action should handle a route, ask if the convention can handle a given controller and action, with the convention adding the routes that it can map to the action. This is basically the reverse approach. Instead of starting with the route and asking different conventions until one can handle the route, it starts with each action, asking each convention in turn if it can give routes for the action. This has two key consequences:

1. Two conventions cannot both provide routes for the same action, since once one convention says it applies to an action no additional conventions are interrogated for additional routes.
2. Two different conventions could each supply the same route for different actions. When this happens, you get an AmbiguousMatchException with the message "The request matched multiple endpoints." While the endpoints are listed, the conventions that gave conflicting endpoints are not.

This makes writing custom conventions more difficult and limiting. Limiting because only one convention can specify a route for an action and difficult because if two conventions specify the same route for different actions, an exception occurs. A convention therefore needs to see if a given route is already mapped to some other action before applying it to the action in question.

At a minimum, the routing structure should ensure that:

1. Two conventions can both provide different routes to the same action, and
2. If two conventions both specify the same route for different actions, the convention with priority (lowest Order number) wins and the same route from other conventions is ignored.

Start with the linked custom OData routing convention documentation and the ASP.NET Core OData 8.0 routing overview to understand the current convention model. Trace the routing structure described in the issue, then verify that multiple conventions can add routes to one action and that lower-Order conventions win when routes conflict.