This is a bigger deal now that libxml2 has tagged these with the deprecated compiler attribute, causing building on debian-experimental to fail (and surely rawhide before too long). As a stopgap we could ignore deprecation compiler warnings.

This is actually only allowed by the pacemaker-next schema, so there's nothing to transform in the 3.10 to 4.0 upgrade. How do we want to go about this? I'm thinking just drop the Pacemaker code for it and leave the constraints-next schema alone until we drop pacemaker-next support altogether.

Re: content, be aware that Pacemaker currently strips text nodes from the CIB. That can be changed but it's possible that certain code (for example, related to XML private data being non-NULL) is relying on the assumption of no text nodes in the CIB. Also be careful that whitespace-only text nodes don't cause problems.

In T745#12714, @kgaillot wrote:

I've already got something ready to go

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)