Lately, every time this library got enhancements, a breaking change was flagged.
Always because of changes to the TypeScript interface Spec.Protocol .

Changes to Spec.Protocol were needed, because new features were required for the normalizers and spec-feature-set description.
The alternative would be to create a new interface with every feature release, and use interface unions that become longer and longer ...

Technically, a change to Spec.Protocol is a breaking-change for one reasons:
the interface is public and downstream implementations (in TypeScript) might break when the interface was changed, but the downstream implementation did not receive matching changes.

Downstream-implementations of Spec.TypeScript is a RARE CASE,
since all needed implementation should happen in this library already. The constants Spec.Spec*dot* takes care of it.
Therefore, I would argue, that it would be okay to make the Spec.Protocol private.
private as in "do not export it to the public".

In addition, to make it clear that this TypeScript interface is not for public use, prefix its name with an _.

result would be, that adding new spec-features would no longer cause a breaking change,

goal:

• rename Spec.Protocol to Spec._SpecProtocol
• have Spec._SpecProtocol not loadable by public exports.
• typedef for the internal interface is still rendered, even it is not publicly acessible. Tools will follow internal imports to know