Haha, don’t worry: rest assured that I didn’t feel offended in the slightest way! But very nice of you to care!
In fact I had a bit of a feeling of being the “old fart” (among youngsters?), when referring to standards and developments from about four decades ago [that’s roughly as old as I am, being around since 1968 …] 
[…] only that terms should be judged on merit alone (proof).
Would you accept as “merit” of a term if that term itself is standardized, in our case for example in ISO 2382-23 Vocabulary – Part 32: Text processing, or if the term is defined in an International Standard related to the subject matter in question, in our case for example ISO 10646?
(I ask just out of curiosity, not that “unordered list” is such a term—unless one counts the mentioned “general document” example DTD as kind-of authoritative, that is—nor any of the proposed alternatives …)
Regarding the remark in the post you refer to above:
However, if consistency with HTML5 terminology is deemed necessary, I’d reluctantly prefer […]
Allow me to add a little rant that in my not-so-humble opinion—from what I have seen and studied of “HTML 5” so far—it rather seems that
consistency with “HTML 5 terminology” is very much a thing to avoid
because it looks like the designers of HTML5 got carried away by an intense desire to use “new, abstracter, terminology” just for the sake of it. For example, re-naming <HR> to “thematic break” (did they really eliminate the phrase “horizontal rule” from the HTML spec?): this is IMO incredibly silly, if not to say stupid, and there are a many other examples like this (just think of the whole “bogus comment” concept and terminology!).
As you can probably guess, I do not hold HTML5 in high regard, and I would certainly not want to use it as an example of —shudder!—consistent use of terminology!
[ I have to admit though that replacing Adobe Flash by whatever kind of HTML5 streaming video element may in fact be worth the otherwise horribly misguided effort that HTML 5 is in my opinion so far … ]
Anyway, the older an engineer, the more spec term changes he proposes.
This may well be because an “older engineer” tends to have seen more needless changes in terminology for the same old concept (introduced out of cluelessness, or out of vanity, or because it’s fashionable), and thus tends to prefer using the same (“old”) terms for the same concepts—a principle which is an instance of Occam’s razor, if you think about it. (Which explains part of my opinion about HTML5.)
We seem to agree on the “issue” of terminology though; I would be (pretty much equally) happy with either
-
“ordered list” and “unordered list” (for said “historical” or “traditional” reasons), or
-
“itemized list” instead of “unordered list” (for LaTeX and DocBook precedence), and maybe even “enumerated list” (for LaTeX precedence) instead of “ordered list”.
Both “bullet list” and “numbered list” are very much tied to a specific presentation style, and are thus not good choices
-
either for naming the CommonMark input syntax construct (ie the text of a list item that starts with “
-” or “+” or “*”, or “1.” etc: this is “just markup”, and for example using “-” and “*” produces the same result anyway (as do for “ordered list items” the input markups “1.”, “2.”, or “3)”, IIRC); -
or for naming the parsing result: these lists are “typically” transformed into
<UL>or<OL>elements (in HTML), or maybe into<ItemizedList>or<OrderedList>elements (in DocBook), and so forth: but in all these target document types, the rendering style of these lists is solely determined by some kind of applicable style sheet (or the whims of a user agent’s defaults, apart from some fuzzy recommendations for “default styles”). And there are lots of ways to “number” the items in a list!
So in the presentation of the result document,
- neither a U+2022 “bullet” character (in “unordered list” items)
- nor a number (in “ordered list” items)
needs to be present, which makes the names “bullet list” and “numbered list” rather obviously not very appropriate for “the output side”, and IMO hence inappropriate for the “input side” too.
To put my point of view bluntly into a simple slogan:
CommonMark is not a style-sheet or formatting language!