The list items definitions in section 5.2 have some “unfortunate” consequences.
Problem report
Consider this list, which is in fact a list according to the spec:
Watch this list:
99999. One below a hundred thousand.
1. One
[ And ignore for now that the vast majority of parsers disagree with "Common"Mark on this one … ]
Now re-order the list items, giving this “list”:
Watch this list:
1. One
99999. One below a hundred thousand.
Ups! The first “list item” has turned into a code block! According to the spec, this is as designed and as it should be. [ And this time this is in fact the “consensus” among parsers. ]
Suggestions
I argue that the expectation that list items (blank-separated blocks containing sibling items on the same hierarchical level) can be re-ordered without side effects like this one is reasonable and well-founded (and that this applies to less pathological cases too).
The easiest remedy would be to change the (debatable) 10-digit limit in rule 1 “basic case” to the maximum number which could satisfy this expectation, namely 4.
And I would also suggest to check afterwards that re-ordering the items in a list is in fact possible (there could be other “corner cases”).
Or: state in the spec that re-ordering of lists is in general not possible, and explain why.