So I see three categories emerging:
- Core: the scope of what currently is in the spec, which all CommonMark implementations need to support.
- Recommended/endorsed/standardized extensions: syntax that the CommonMark project (either through a section in the spec or through a separate document) endorses and says: “if you are going to implement this feature (e.g. footnotes, definition lists, etc.), then you SHOULD use this syntax here.” (Or if each extension is published in a separate document, it could even say: “you MUST use this syntax.”) Of course we must make sure that endorsed extensions are in no conflict to another whatsoever.
- Custom extensions: all extensions that haven’t been officially endorsed by the CommonMark project.
Since every string is valid markdown, you can always construct cases where an implementation that supports an extension outputs different HTML than an implementation that doesn’t. That’s why the core spec doesn’t say that all implementations must behave the same way on all input strings, but rather that there are these extensive test cases for all features in core and that all implementations must behave the same on those. Endorsed extensions would then just add a few test cases and implementations that claim to support an extensions need to pass those. That way extensions can be cherry-picked by implementors while still remaining compliant to the spec.
It would be nice if some of the authors (@jgm, @codinghorror) could quickly chime in and say which direction they think is most appropriate for “endorsed extensions”. That is: add section to current spec or publish in separate document(s)? work on this already now or wait till core has reached 1.0?