The numbers of subsequent list items are disregarded.
IMO this is too strong: I can see many cases where the source code itself is useful (and as it happens, this is exactly my case: I’m switching class notes to commonmark so that the text sources are usable too). In such cases I’d love to flip on some flag that makes a renderer barf if the numbers I write don’t match up so I can be sure that the rendered version and the source are in agreement.
So I think that it’d be better to allow renderers to do that rather than to always force them to ignore the non-first numbers. For example, something like:
The numbers of subsequent list items are disregarded for rendering purposes, but a renderer can throw an error if a number wouldn’t match the rendered result.
except phrased better than what a sleep-deprived-non-native-speaker can produce.
I don’t know what exact meaning of linting you have in mind, but it usually is something close to what WP defines it as (“flaggs suspicious and non-portable constructs (likely to be bugs)”).
What I’m talking about is allowing these things to be proper errors, not just warnings or suspicious things. To clarify my use case as an example: I use md-text files during an exam (as text) and to render it as html: this is an extreme case of using the source as-is in addition to rendering it – extreme since a mistake in the numbers can be a disaster (multiple choice question getting the wrong numbers).
IMO such use cases are valid exactly following the original “should be publishable as-is”. The only thing that I’m asking for is to remove “disregarded” as a requirement, allowing bad numbers to be treated as real errors.
(Alternatively, if you’re talking about a separate tool, then it seems redundant to have such a thing separately from a renderer.)
I’m thinking it’s analogous to -Wall and -Werror flags in compilers. With -Wall you turn on some optional warnings, with -Werror you say “treat these as errors.” Adding flags like these to a C compiler doesn’t require changes in the compiler spec.
So, your CommonMark parser could have a flag saying: “in addition to parsing according to the spec, I want you to check certain further conditions and raise an error if any of them occur.”