special casing fallback behavior when attribute is set to null will make it more difficult to tool against

[tylerjw]

Note that a value of null satisfies the condition of having the attribute. A value of null 
has the usual meaning where null is an acceptable value for the attribute; otherwise, a value 
of null shall be treated as the attribute being unset (and shall suppress falling back to the 
non-configuration-specific value).

In JSON parsers, where you specify a structure of types and the parser tries to fill out those types, typically an unset attribute and an attribute set to null both results in a None value in an optional. In cases where you must tell the difference between an unset value and a null value, you'll end up with a nested option type. This makes it much more challenging to tool around this spec.

It would be much easier if tag: null meant the same as the tag not being specified. If you want to unset the values and not allow a fallback, set the value to an empty string or array. For example tag: [] or tag: "" would cause an overriding to an empty value.

[tylerjw]

It would be easier to tool against this if it read:

Note that a null value is the same thing as not specifying the attribute. To suppress
falling back to the non-configuration-specific value, specify a valid value such as 
0/""/[]/{}.

[tylerjw]

I found another use of this sort of special-casing null here: https://cps-org.github.io/cps/schema.html#requires-package

Values are a valid requirement object or null (equivalent to an empty requirement object) 
describing the package required.

I prefer this wording for the sake of tooling:

Values are a valid requirement object or an empty object.

[autoantwort]

Imho we should simply remove that. This also makes it harder to write a schema for it.

[mwoehlke]

I prefer this wording [...]

Yes, I guess we should change that also, but an empty object is a valid Requirement; "or an empty object" is redundant.

Values are a valid requirement object
describing the package required.