What's the logic behind Polkadot's choice in pallet indexing?

Question

In most runtimes in production, each pallet has a specific index but its not clear what the logic behind ordering them really is. For example, in Polkadot we can see a comment in the construct_runtime macro that alludes to a decision made around anticipating future pallets that would need to be within a specific index range. We can also observe that XcmPallet has an index of 99:

        // Parachain Onboarding Pallets. Start indices at 70 to leave room.
        Registrar: paras_registrar::{Pallet, Call, Storage, Event<T>} = 70,
        Slots: slots::{Pallet, Call, Storage, Event<T>} = 71,
        Auctions: auctions::{Pallet, Call, Storage, Event<T>} = 72,
        Crowdloan: crowdloan::{Pallet, Call, Storage, Event<T>} = 73,

        // Pallet for sending XCM.
        XcmPallet: pallet_xcm::{Pallet, Call, Storage, Event<T>, Origin, Config} = 99,

What's the logic behind Polkadot's choice in pallet indexing? What is the significance of a pallet's index and what do runtime engineers need to consider when numbering the pallets in their chain's runtime ? It would be great to get an answer that could help other parachain developers make the right pallet indexing decisions for their chain.

Answer 1

The main consideration when choosing indices is that it's generally much better for signing infrastructure if the index for a particular pallet (and therefore its call type) doesn't change. Especially for hardware wallets, where firmware updates have more friction. When indices don't change, it gives better backwards compatibility in the binary format of extrinsics.

Runtime developers should typically be explicit about the indices that correspond to pallets, and if there are groups of pallets that are similar or related it's convention to cluster them together. This leads to developers spacing out pallets and leaving room between them for new pallets to be inserted without affecting any other indices.