Thanks @mofosyne. I’ve thought about it some more and I’m updating my answer.
First, see my new post on the need for flavors. I think your proposal is close to what I’m saying there.
Second, any proposed alternate such as yours needs to be identified with a prerelease-identifier in holding with the Semantic Versioning concepts, before it advances to sanctioned flavor status. The prerelease string identifies that its a spec in development. My suggestion would be something that anyone could do for themselves, and that we adopt a convention that helps people find details on any proposal, such as having the pre-release string be like github.username.projectname of a fork of the main project files. . In this fork, spec.txt should be updated with the prerelease-string appended to the version number, and edited to reflect what’s different in the proposed flavor. While it’s in prerelease state, the version numbers used would be arbitrary within that project. During this period, the right declarant tag might look like <!CommonMark 0.1.23-github.username.projectname>.
Then, assuming a community develops that supports the proposed variant, there’s at least one stable implementation that passes all the tests in the new (edited) spec.txt, and consensus is reached, then the edited spec.txt is sanctioned by publication as a stable baseline in subdirectory of a CommonMark.org web site. At this point the variant gets an official name (the name of the subdirectory, lets say it’s called Foo) and stable version number, that might be 1.0.0. Then, the recommended declaration becomes <!CommonMark Foo/1.0.0>, but implementations are fee to still recognize/process the pre-release identifiers if desired.
Does that answer your question?