Front Door Service - Create Rule - Order Conflict

Trying to create a new rule and insert it into the current list of rules at a specific position is very difficult to achieve.
The Front Door REST API service seems to occasionally reset the value of the `properties.order` property on every rule to start at `10` and increment each by `1` every now and then - I'm not sure what triggers this.

So if there are 20 rules, and I want to insert my new rule right in the middle of the ruleset, I'm forced to increment the last 10 rules by at least one to make a spot for my new rule. Every one of these updates to each rule can take a minute to process and often fails if you don't to wait another minute in between each update so that the previous update is reflected prior to the next update. After all this and 20 minutes later of updates and delays, some random trigger internally may reset the `properties.order` property of every rule again.

This is required because there is a restriction on the create and update calls to ensure that no other pre-existing rule has the same value for the `properties.order` property.

I would propose a different approach based on other insert logic implemented quite often. If an existing rule has the same order as the new rule, then the new rule is inserted in its place and the existing rule has its order automatically incremented along with all other rules that are after it - just automatically shift all other rules further down the order. Since the service seems to reset the order anyways periodically, there should be no issue with this approach.

Please let me know if there is a better way to insert a new rule into the middle of a large ruleset.

https://learn.microsoft.com/en-us/rest/api/frontdoor/azurefrontdoorstandardpremium/rules/create

Thank you.

No repository file or test is identified. Start by reading the linked Azure Front Door Standard/Premium Rules - Create REST API documentation and determine whether the requested ordering behavior belongs in this API specification repository or requires a service change. Done would require an API-owner decision and an actionable specification change.

Written by the indexing model from the issue text.