We’re right in the middle of personal preferences here, and I wouldn’t want to guess what “some people” do or don’t, and why they would, and use my guesstimates about it as an argument.
The one argument not based on personal taste (and personal typing habits or personal visual recognition capabilities for that matter) that I offered—namely the several decades of using exactly this convention in typewritten documents—you either fail to understand or you disregard for some unstated reason.
And I for one fail to see what’s so hard about seeing the difference (while editing text) between one SPACE or more than one SPACE following a Digit or NUMBER SIGN. This has nothing to do with my use of “⎵” to emphasize certain SPACE characters in examples: I can assure you that I can see said difference quite clear and easily in your included “setext” example, and don’t tell me you could not (while writing that example text) …
However, since the number signs in ATX headings are not separated in any way, this would establish a third way to denote headings in Commonmark, except for the top level obviously.
Well yes, let me count: we would have (1) ATX headings, like before; (2) setext headings, like before; but new (3) decimal-numbered section headings. Each with an own syntax, each with its own, different meaning (well, no: (1) and (2) have the exact same meaning …). It was my point that this would introduce a “third way” to denote headings, and because this would correspond to a different kind of headings, I can’t see where you see a problem here.
I deny the applicability of the double-space convention to CommonMark, therefore – even if something like this was adopted – it depends on the parser settings and output format capabilities […]
I can’t make sense out of this paragraph:
-
You deny the “applicability” (whatever that means) of said syntax: fine, I do affirm it.
-
And therefore “it” depends on “parser settings”? You deny something, and this is the reason that something depends on “parser settings”? I’m sorry, you have to help me out here.
[…] whether any of the following headings is actually rendered with a leading number.
Well, yes, it is an established fact that how everything is rendered what comes out of a CommonMark processor (with or without a leading number, bold or condensed, red or black, centered or block-justified, on and on) is outside of the reach of both the specification and the processor of CommonMark.
Maybe you understand my position when I explain it this way: remember that the point (that is, “meaning”, or “reason of existence”) of the—existing, long-established!—input numerals in “ordered” lists is:
-
as a “strong hint” that “some form of” numbering, or individually labeling, the list items is desired in the presentation (in contrast to items in an “unordered” list);
-
as a way to specify (the first in the automatically generated sequence of) item numbers.
This is not my opinion, this is simply paraphrasing the CommonMark (and Markdown) specification.
And it is exactly the same two purposes, to repeat and paraphrase:
-
as a “strong hint” that “some form of” numbering, or individually labeling, the section heading is desired in the presentation (in contrast to ATX and setext headings);
-
as a way to specify (the first in the automatically generated, hierarchical sequence of) section numbers.
So any argument you bring forward against distinguishing (in the input syntax) “numbered” and “plain” section headings immediately translates into an argument against distinguishing (in the input syntax) “ordered” and “unordered” lists.
But you seem to argue that distinguishing two types of lists is good, while distinguishing two kinds of section headings is bad, practically solely by reference to what “some people” supposedly do or can or want?
I’m saying that too many people would not see the difference between 1.2 and 2. introducing a line, […]
if they can see that the line you are talking about is either (1) separated by blank lines, or (2) part of an indented run of text containing multiple lines which start in the same way (maybe one could call this “run of text” a … let’s see: “list”?), if they can see this context and still would not see the difference between 1.2⎵⎵ and 2.⎵ introducing a line – then I’m sorry to say that maybe they are unfit for any kind of text processing.
By the way, I forgot to mention something else—this is important:
The main reason why I started to use “⎵” as a “visible” SPACE was in fact not curiosity of mine nor courtesy for the reader, but rather the shi^H^H^Hspecial Markdown processing employed by this site: try, for example, entering
"`1. `"
that is (QUOTATION MARK , GRAVE ACCENT , DIGIT ONE , FULL STOP , SPACE , GRAVE ACCENT , QUOTATION MARK ) not in a code block, but “inline”, like here: "1. " – can you see the SPACE after DIGIT ONE? I can’t either, because it gets discarded by this abomination of a would-be Markdown processor!
Now try the same, this time replacing U+0020 SPACE with U+00A0 NO-BREAK SPACE: this gets discarded too!
You can’t of course use a character reference either here, because of the “backticks”!
But the funny U+23B5 BOTTOM SQUARE BRACKET character (copy-and-pasted into the text out of the fabulous BabelMap application, which you absolutely should know and use!) somehow evades this ruthless parser, and heroically makes his way right to the end, into your and mine user agent, where it just looks like a “visible SPACE”, exactly as if yours truly, the author, had nothing else in mind from the start but the reading pleasure of anyone lurking around this curious site … 
So that’s why, if you ask me.