Dimension.localizationKey of a custom dimension is a per-world saved id, not a key a pack can name

Dimension.localizationKey on a custom dimension returns dimension.dimensionName1000 and up, on from the vanilla dimensions' dimension.dimensionName0 through dimension.dimensionName2. The number is a runtime id the world hands out the first time it sees a dimension, in alphabetical order of identifier among the dimensions that are new to it at that moment, and then keeps in the save. Pack order and file name play no part. So the same dimension has one key in a world created with both packs and another in a world that had one pack before the other was added, and keeps whichever it was given. The key carries neither the dimension's namespace nor its name, so nothing in the dimension's JSON or identifier tells a pack what the key will be, and a lang file cannot carry a line for it ahead of time.

Every other registry derives its key from the identifier (entity.creeper.name, item.apple.name, tile.stone.stone.name)

The repro is two behaviour packs, each with two custom dimensions in one namespace, so the pack order can be swapped and the file names set against the identifiers:

| Pack   | Dimensions                                                               | Script                               |
| ------ | ------------------------------------------------------------------------ | ------------------------------------ |
| Pack A | `ss_cdl:first`, `ss_cdl:second`                                          | `/ss_cdl:bug_report`, reads all four |
| Pack B | `ss_cdl:third` (in `a_third.json`), `ss_cdl:fourth` (in `z_fourth.json`) | none                                 |

Pack A's resource pack carries every identifier-derived spelling of its two dimensions' names, plus lines for dimension.dimensionName1000 through 1003 that say only which index they are, so the screen shows which line resolved.

Steps to reproduce

1. Import both attached add-ons, custom_dimensions_dimension_localization_key_pack_a.mcaddon and custom_dimensions_dimension_localization_key_pack_b.mcaddon.

2. Create a new flat world with both behaviour packs and Pack A's resource pack applied (no experiments needed).

3. Run /ss_cdl:bug_report keys. The pack logs localizationKey for the three vanilla dimensions, the four pack dimensions, and for comparison the key an entity type, an item type and a block type report.

4. Run /ss_cdl:bug_report show first, show second, show third and show fourth. Each prints the dimension's key and puts it through a translate in chat and on the action bar, as any pack message naming the dimension would.

5. Create a second world with the two behaviour packs ranked the other way round and repeat step 3.

6. Create a third world with Pack A alone, run step 3, save and quit, add Pack B to the world, and run step 3 again.

Expected result

A custom dimension's key is spelled from its identifier, as the other registries do, so pack_keys_derived_from_identifier in step 3 lists all four dimensions and the result is keys_name_the_dimension. Step 4 shows one of the identifier-derived lines from the lang file (for example "First (colon key)"), and a pack author can name a dimension by writing that line. The key of ss_cdl:first is the same in every step, because it depends on that dimension alone and not on what else is loaded.

Observed result

Step 3 logs, in the worlds created with both packs (steps 2 and 5, either pack order):

"vanilla_dimensions": {
  "minecraft:overworld": "dimension.dimensionName0",
  "minecraft:nether": "dimension.dimensionName1",
  "minecraft:the_end": "dimension.dimensionName2"
},
"pack_dimensions": {
  "ss_cdl:first": "dimension.dimensionName1000",
  "ss_cdl:second": "dimension.dimensionName1002",
  "ss_cdl:third": "dimension.dimensionName1003",
  "ss_cdl:fourth": "dimension.dimensionName1001"
},
"comparison": {
  "minecraft:creeper": "entity.creeper.name",
  "minecraft:apple": "item.apple.name",
  "minecraft:stone": "tile.stone.stone.name"
},
"pack_keys_derived_from_identifier": [],
"result": "keys_are_registration_indices"

The four keys follow the identifiers in alphabetical order (first, fourth, second, third), regardless of which pack ranks higher and regardless of file name (a_third.json sorts first by file name yet holds the last index). The world from step 6 gives different keys for the same four dimensions. With Pack A alone, ss_cdl:first is 1000 and ss_cdl:second is 1001. After Pack B is added, those two keep their numbers and the newcomers take the next two, again in identifier order:

"pack_dimensions": {
  "ss_cdl:first": "dimension.dimensionName1000",
  "ss_cdl:second": "dimension.dimensionName1001",
  "ss_cdl:third": "dimension.dimensionName1003",
  "ss_cdl:fourth": "dimension.dimensionName1002"
}

So ss_cdl:second is 1002 in one world and 1001 in another, and ss_cdl:fourth is 1001 in one and 1002 in the other, with the same two packs applied. The number is assigned when the world first sees the dimension and saved with the world. Step 4 shows the "Index 1000" to "Index 1003" lines from the lang file and never an identifier-derived one. With the index lines removed from the lang file, the player sees the raw key on screen, which is what a pack ships today if it uses the property at all.