I'm thinking the simplest approach might be to consider the "inheritable" meta-attributes as separate to each layer. For example there is a group resource-stickiness meta-attribute and a different primitive resource-stickiness meta-attribute. That way each could have its own description of how it behaves. Primitive resource-stickiness keeps the current description from Pacemaker Explained, group resource-stickiness gets something like "Default value to use for members' resource-stickiness if not explicitly set for the member. The group's own stickiness is not this value, but the sum of its members' stickiness." The primitive default could even be described as "Value of resource-stickiness in group meta-attributes if set, otherwise value of resource-stickiness in clone meta-attributes if set, otherwise value of resource-stickiness in bundle meta-attributes if set, otherwise 0, plus 1 for promoted clone instances of the primitive" though that sounds horrible.

In T620#11565, @nrwahl2 wrote:

Meta-attribute inheritance is weird. I've just started looking at groups. Very much non-exhaustive:

• is-managed: Any false wins. If is-managed=false for the group and is-managed=true for a primitive, the primitive is unmanaged.
• maintenance: Any true wins. Similar to is-managed but reversed.

In T800#11838, @nrwahl2 wrote:

<define name="non-empty-string">
   <data type="string">
      <except><value></value></except>
   </data>
</define>

It turns out that due to the same normalization you described, any value that consists of only spaces is rejected. Not just empty strings.

Which might be fine for our purposes, but we need to be aware of it.

For this task, we only need a deprecation warning. When we get around to dropping support for master, the code won't have to worry about it at all -- an XSL transform will map master to clone before the code ever sees it.