We should probably split this into two: creating the new category and updating the tooling to support replaced_by, etc. I'm not sure the replaced_by is necessary at this point since we haven't really "published" this, but in either case, these are related but separate concerns.

Agreed that this is a great long term value add. Let's not track renames yet, though.

Do we want to keep track of the "holes" left when we rename criteria?

Do we want to keep track of the "holes" left when we rename criteria?

My inclination is "no". My take is that we're currently in a pre-release with no API stability promises, so it's okay to make the sort of changes that we wouldn't later.

Do we want to keep track of the "holes" left when we rename criteria?

My inclination is "no". My take is that we're currently in a pre-release with no API stability promises, so it's okay to make the sort of changes that we wouldn't later.

Do we want to plan then to renumber the existing criteria to collapse the holes that will be left by moving things around?

(Sorry to push on this, but I worry about confusing ourselves as well as other consumers with gaps in the numbering.)

I think it's fine pre-release. I do think we want to ensure that post-release we are consistent.

Do we want to plan then to renumber the existing criteria to collapse the holes that will be left by moving things around?

I was about to say that I don't have a strong preference, but then I realized I think I do. I'm in favor of renumbering, since later on the holes will only be in presentation. (E.g. there won't be an OSPS-XY-123 in the published version, but OSPS-XY-123 will exist in the yaml as a deprecated/renamed/whatever item)