Questão contratual, evitar ambiguidades ou obrigatoriedade inconsistente

[ppKrauss]

Tendo em vista que a norma é referenciada em contratos, o acesso a cada subversão (no caso a v1.1.0) precisa ser preservado. Justamente por isso, sugere-se revisar o texto sobre versões suportadas, algo como acrescentar o texto "subversões não são obrigatórias, mas recomenda-se o upgrade quando não houver conflito contratual na adoção da subversão".

No presente caso da v1.1.1 parece que houve upgrade dos valores permitidos no atributo publication-type: como o upgrade não pode agir retroativamente sobre o contrato de um fornecedor, não se pode obrigar a mudança das práticas já adotadas e aceitas anteriormente (v1.1.0), pode-se apenas recomendar que mude.

---

Duas versões são suportadas simultaneamente, a mais recente (e.g. v1.1) e a imediatamente anterior (e.g. v1.0). [...].
Subversões não são obrigatórias, mas recomenda-se o upgrade quando não houver conflito contratual na adoção da subversão.

[ppKrauss]

... a rigor as atualizações por subversão não deveriam ter impacto normativo, apenas didático ou de layout. Uma nova regra, por mais sutil e insignificante que pareça, deveria ser acrescentada apenas na versão futura (não-vigente).

A sugestão anterior (#37) foi de se distinguir "subversões com novas deliberações" de "subversões com correções de texto".

O caso de "novas deliberações" é que cria o problema que descrevo, de impacto sobre regras já entendidas de outra forma em subversões anteriores... As "novas deliberações":
ou devem ser evitadas,
ou devem comparecer na norma com algum aviso de "não-retroatividade".