Spec: need clarification about keys x_ in prereqs

[dolmen]

The spec says about keys x_:

Any keys not described in this specification document (whether top-level or within compound data structures described herein) are considered custom keys and must begin with an "x" or "X" and be followed by an underscore; i.e. they must match the pattern: qr{\Ax_}i. If a custom key refers to a compound data structure, subkeys within it do not need an "x_" or "X_" prefix.

Consumers of metadata may ignore any or all custom keys. All other keys not described herein are invalid and should be ignored by consumers. Producers must not generate or output invalid keys.

This implies that custom keys are allowed anywhere in prereqs, so any module starting with X_ or x_ can not be specified as a prereq as it may be ignored. Is that really the intent?

Here is an example:

{
    "prereqs": {
        "runtime": {
            "X_M_L": "v1.0",
            "X_Factor": "v1.0",
            "X_": "1.002"
        }
    }
}

[miyagawa]

I doubt it because it only applies to "Any keys not described in this specification document" and later, the value of such prereqs Maps is defined as "a Map of package names to version ranges" so that "x_" rule won't apply.

Your quote also says "All other keys not described are invalid", which means "x_" rule doesn't apply here, since otherwise any package names that does not begin with "x_" would be considered invalid.

[Leont]

Things could be worded better, but effectively I don't think the desired semantics are ill-defined here.

[dolmen]

provides has the same issue.

[miyagawa]

It says " The set of relations must be specified as a Map of package names to version ranges." so the meaning of the keys are already defined as generic package names. x_ rule only applies to the keys that is not defined in the spec.

I don't disagree that there could be a better wording on which field the x_ rules could apply, so that such misreading wouldn't happen.