This breaks backward-compatibility for anyone who might be using the value 'statement', which is no longer permitted.

Please consider adding new value(s) but not removing any values already enumerated, at least until a 2.0 version.

@wendellpiez The value statement for group/part@name was proposed by me in the initial PR and contested by Dave (see his comments). I followed his suggestions and replaced it with instruction. It is not in our current schema. Can you please elaborate on where do you see a backwards compatibility break?

If the value is not in the current schema (and only being removed from the file in the branch), I retract my objection. Adding new values to the reserved namespace is fine.

I'm not super keen on 'instruction' however either - what is the requirement being addressed by it? Since users are free to mark parts in their own namespace however they like, or leave parts with no name. Is there a specific behavior to be attributed for the 'instruction' that could not be met, for example, by

<part>
  <title>Instructions</title>
  ...
</part>

which is already valid?

These are not blocking questions, but I ask because afaik they have not been addressed.

FWIW, not having a registry is not in itself a reason to add new values to enumerated lists. They still incur costs to downstream developers.