(with a little magic to re-allow the old name as a custom name after a CIB has been upgraded).

Do we want this immediately? This doesn't even require magic, it's the default behavior if we don't ban the old name in the new schema. However, last time we talked in Slack:

the idea is to prevent the newly dropped options from being used after the transform (at least until the next transform)
user has old CIB with dropped option: implicit upgrade drops the option
user has new CIB after option is dropped: can't add option
user has even newer CIB much later: can add dropped option as custom name
(schema major version X, X+1, X+2)

In T807#12633, @nrwahl2 wrote:

(with a little magic to re-allow the old name as a custom name after a CIB has been upgraded).

Do we want this immediately? This doesn't even require magic, it's the default behavior if we don't ban the old name in the new schema. However, last time we talked in Slack:

the idea is to prevent the newly dropped options from being used after the transform (at least until the next transform)
user has old CIB with dropped option: implicit upgrade drops the option
user has new CIB after option is dropped: can't add option
user has even newer CIB much later: can add dropped option as custom name
(schema major version X, X+1, X+2)

I lean to following however it was done last time. That was my understanding but I didn't look closely at it