If I understand your index.json file correctly, you provide support for multiple toolchain releases, including the latest 12.x.

Any reasons for not also including the 11.x? At least the latestv11.3.1-1.1.2?

Toolchain is linked to a release so next one will be with v12.

Your index.json lists the following:

• "9.3.1-1.3"
• "10.2.1-1.1"
• "10.3.1-2.3"
• "12.2.1-1.2"

I confess that I don't know how this file is used, but if users can select any of the above releases, I think they should also be allowed to chose "11.3.1-1.1", even if the latest one is "12.2.1-1.2".

No user could not select the toolchain. The release give their tools dependencies.

No user could not select the toolchain.

I see. But then why are those old definitions still present in the JSON file?

No user could not select the toolchain.

I see. But then why are those old definitions still present in the JSON file?

Because all release are available. User select the core version and then tools dependencies are selected.

To go further, the .json provides all information to install a specifc core version.
Ex here the 2.0.0:
https://github.com/stm32duino/BoardManagerFiles/blob/b815bc0f5ae37ec571dd9f7829d060dbebdb0382/package_stmicroelectronics_index.json#L15
which provides the tools dependencies:
https://github.com/stm32duino/BoardManagerFiles/blob/b815bc0f5ae37ec571dd9f7829d060dbebdb0382/package_stmicroelectronics_index.json#L49-L65

So 2.0.0 request to have gcc version 9.3.1-1.3

For the next 2.5.0, the 12.2.1-1.2 will be required.

I'm not familiar with the Duino versioning scheme, and I don't know how much freedom you have with your releases, but, from the toolchain point of view, it is useful to have the choice to build a project with a specific version. Can you go back in time and insert an intermediate release, like 2.4.x, configured with GCC 11.3? Or make 2.5.0 with 11.3, and 2.5.1 with 12.2?

Honestly, I see no reason for doing this nor the interest.