Flexible frontend prefix matching without using 'matching order' field?

We allow end-users, of the Apinf platform, to add API Umbrella API backends, including defining a custom frontend prefix. This has led to some problems, such as the following frontend prefixes resolving to the wrong API Backend:

Intended:

• /music - initial frontend prefix added by user
  • Intended -> resolves to 'Music API: root'
  • Actual: works as expected
• /music/alternative/ - second frontend prefix added by user
  • Intended -> resolves to 'Music API: Alternative
  • Actual: respoves to 'Music API: root'

We are noticing that API Umbrella uses a global matching order field to mitigate this issue. However, in our current UI, a global 'matching order' might not make sense to a user who has just added one or more APIs, but who may not be responsible for the remaining APIs.

What are some ideas as to how we might allow end-users to add APIs, so that calls resolve in an intuitive/expected way?

The issue names no files, tests, or entry points. Start by reviewing how frontend prefixes and the global matching order currently resolve requests, then define a user-facing resolution model that avoids requiring unrelated APIs to be ordered; done means the expected behavior and scope are agreed.