From the section Deimorz linked:

> The point is, if you want to, you can use ordinal numbers in your ordered Markdown lists, so that the numbers in your source match the numbers in your published HTML. But if you want to be lazy, you don’t have to.

However, the complete disregard for the actual numbers seems to have been for ease of implementation in markdown.pl (the original implementation, which is what this doc is describing). The next paragraph notes:

> If you do use lazy list numbering, however, you should still start the list with the number 1. At some point in the future, Markdown may support starting ordered lists at an arbitrary number.

> starting ordered lists at an arbitrary number

The solution would need to be not just that, but also letting every li be arbitrarily enumerated. And at that point it's not even an ol, it's a ul (from a machine perspective) where the author might happen to mimick an ol. Or just nothing structured at all -- which would probably be a net positive.

The underlying HTML <ol> element allows arbitrary values through the value tag.

One of the original selling points of Markdown (at least in Gruber's post) is that is "seamlessly integrates" with HTML, in that you are in principle able to mix and match Markdown and HTML and get predictable HTML output. I think it was that aspect of Markdown that let it be so... sloppy?

That aspect of Markdown seems to have fallen away with the rise of Markdown extensions and standards.

It’s a really convenient property if you’re maintaining long lists since you can easily re-order items in a list without having to re-number each item.

Yeah, it's great for wikis. Less so for forums.

It seems like for those situations it would be much nicer to just have something like \item in LaTeX. It's still readable in plaintext, but wouldn't break things.

That's a perfectly reasonable use case that should be supported. But it should require explicit activation (a tag, etc). A formatting engine should not rewrite content unless told to explicitly.

The fact is that Markdown is not a very good design but became the standard. So this is just a cross one must bear.

By single space do you mean using a line break instead of a new paragraph? Markdown does allow for this: https://daringfireball.net/projects/markdown/syntax#p

Let's say you have a list with 50 items and want to add one item in between. Instead of updating all the indexes, you just type a number and Markdown does that for you.

In any case, it can be escaped by writing 1\. instead of 1.

I can't think of any reason I would want half my list indexes to be wrong in my source file.

I can think of plenty of reasons I would want to use auto-numbers while removing explicit numbers. But this is insane as a default behavior.

> I can't think of any reason I would want half my list indexes to be wrong in my source file.

Agreed. The bit about "oh, well, it fixes mistakes if you rearrange items" falls in the astonishing (in a bad way) camp far too often. When you really meant to number the lines, "2, 4, 6, 8" and it "helpfully" changes this to "1, 2, 3, 4". Arguably it's bad also in a list that has been maintained over time and has out-of-sequence numbers, where the users are counting on the processor to renumber - now, if someone says to change item 37, is that the one numbered 37 in the rendered output, or in the source? Better to use a tool of some sort to physically renumber that section of the source document.

A better alternative for auto-renumbering would be to only have it kick in when the entire list all starts with "1. " and there's more than one line in the list (so "...meet me at<next line>1. Then we'll..." doesn't end up with a line being dragged into being a numbered list). Then, the repeated use of "1. " at the start of the line becomes a much more obvious indication that you want to numbered list.

> won't allow you to single-space text except in a code block

Why do you want to single-space your text though?

Because I want to present a list of items, or some reference URLs, or a poem, without tons of unnecessary white space.