Does it work if you use correct indentation? That is, a single tab or four spaces?

A correct Markdown should look like this (I've replaced spaces, 0x20, with the Unicode Open Box chatacters, U+2423, for illustration purposes):

This is a paragraph.

␣␣␣␣- This is an item.

␣␣␣␣␣␣␣␣This list looks a-ok:

␣␣␣␣␣␣␣␣␣␣␣␣* Item 1

␣␣␣␣␣␣␣␣␣␣␣␣* Item 2

␣␣␣␣␣␣␣␣This list, not so much:

␣␣␣␣␣␣␣␣␣␣␣␣* Item 3

␣␣␣␣␣␣␣␣␣␣␣␣* Item 4

See the spec for more info.

Actually, your code example is wrong. That official spec you mention explicitly forbids indenting the list marker by more than 3 spaces (presumably because then it'd be interpreted as code -- in fact, that's exactly what happens with your code example, at least here in the forum). It does say that any subsequent paragraph must be indented by 4 spaces (or 1 tab), but my example code was already doing that:

␣␣-␣This is an item.↵
↵
␣␣␣␣This list looks a-ok:↵
↵
␣␣␣␣␣␣*␣Item 1↵
↵
␣␣␣␣␣␣*␣Item 2↵
↵
␣␣␣␣This list, not so much:↵
↵
␣␣␣␣␣␣*␣Item 3↵
↵
␣␣␣␣␣␣*␣Item 4↵

What bugs me is that the official spec you linked doesn't even mention the ability to put lists within lists, which must be a fossil extension (and I've also found in virtually every markdown implementation I've ever seen) -- the spec does mention paragraphs, blockquotes, and code blocks within list elements, but not nested lists. (Nevertheless, the "Dingus" link in the spec does support nested lists, and it even mentions that they're supported in the cheatsheet; my original code generates the expected result there.)

Fossil, however, explicitly states that this is allowed. But, to be fair, it doesn't say that it is OK to mix that with paragraphs (but one would expect that it is).

I've tried multiple variations, but to no avail:

• Do not indent the list marker, and add 3 spaces after it (and 4 spaces for subsequent paragraphs).
• Remove the blank lines separating the paragraphs (except at the end of the first nested list).
• Preserve the blank lines, but add 4 spaces to them to preserve the "continuity" of blocks (those spaces seem to be ignored anyway).
• Use tabs instead of spaces.

There seems to be a way to "break the spell" if some weird block goes right before the second list (in this case, a code block):

  - This list looks a-ok:

      * Item 1

      * Item 2

    This list, not so much:

        indented code block

      * Item 3

      * Item 4

results in:

• This list looks a-ok:

  • Item 1
  • Item 2

  This list, not so much:

  indented code block
  

  • Item 3
  • Item 4

This is one of the ambiguities in Markdown. John MacFarlane, author of pandoc, and major contributor to commonmark, offered the following:

Beyond Markdown

where section 5 Lists and Blank Lines has considerable discussion related to your issue.

MacFarlane has developed djot, as a modern improvement on Markdown. It is very new and might have trouble convincing the Markdown world that it is a better way.

I don't think there's any ambiguity here, at least not one justifying fossil's interpretation. There is a blank line between "This list, not so much:" and "* Item 3", so there's no reason why the latter should be considered a continuation of the former line. (Precisely the solution offered in the link you shared is to add a blank line, which I have already added.)

If there were no blank line between the two I would understand the ambiguity (although fossil's documentation shows that such a blank line is not needed, in principle), but with a blank line I see no reason why "* Item 3" would be considered as a continuation of "This list, not so much:".

In short, I'm pretty sure this is a bug.

PS: Just to clarify, note that my initial example had one blank line between every code line (I just realized that it might have looked like the format used a large line spacing, but there are actually blank lines in the middle):

 1|This·is·a·paragraph.¶
 2|¶
 3|··-·This·is·an·item.¶
 4|¶
 5|····This·list·looks·a-ok:¶
 6|¶
 7|······*·Item·1¶
 8|¶
 9|······*·Item·2¶
10|¶
11|····This·list,·not·so·much:¶
12|¶
13|······*·Item·3¶
14|¶
15|······*·Item·4¶

Actually, your code example is wrong

Yes, for some reason I thought the first line in your example was itself a list item.

the official spec you linked doesn't even mention the ability to put lists within lists

This is incorrect. It says:

List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab

…and a list is just one of the things which may constitute a paragraph. Due to this rule, to put a list in a list item, the items of the nested list must be indented by 4 spaces or a TAB, and a code block (if not "fenced") — by double that amount: one for "indenting" and another one — to make it "code".

No, I'm not saying the original Markdown spec is well-formulated, but this particular claim is unfounded.

…and a list is just one of the things which may constitute a paragraph.

I'm not sure I agree with this interpretation of yours; the spec doesn't say anything about lists being paragraphs, at least not explicitly. In fact, "lists" and "paragraphs" appear as two different subsections under the "Block elements" section (and the spec doesn't say anything about lists being able to contain multiple "block elements", only multiple paragraphs, or blockquotes, or code blocks). But in any case I would be surprised if the author didn't consider the possibility of having nested lists; it's just that it doesn't seem to be mentioned explicitly in the spec.

Anyway, all semantics aside... is there a "right" way to write my original Tcl snippet so that will work in Fossil? So far everything I've tried has failed (and all that's been discussed here are possible reasons why my code was wrong, but not what the right code should look like).

I'm not sure I agree with this interpretation of yours; the spec doesn't say anything about ...

Though i'm neither agreeing nor disagreeing with any given viewpoint on this, i feel compelled to pedantically point out that we've never claimed any compliance with The Spec. That is only to say that what The Spec says has little bearing on how fossil behaves. By and large, it complies with common markdown conventions (whether formally specified or not). It may well differ from The Spec in advanced or esoteric cases, and that's just how it is (neither bug nor feature).

Sure :) I was just quoting The Spec because that's what I was given as "proof that my code was wrong". I suppose it'd be a better idea to quote Your Spec, which is an extension over the original spec (adding tables and other cool stuff), but unfortunately that one doesn't answer my question either.

In any case, I posted this in the forum just because it looks like a bug to me (as it behaves differently to every other Markdown implementation I've ever seen), and I thought the devs might be interested in it so that they can try to fix it (in case they determine that it is indeed a bug).

Just chiming in here to show by example that most markdown implementations render the "expected" output, with the two paragraphs & sub-lists nested under the first list item.

Thanks; that's precisely the behavior I expected.

So, what's the verdict? Do you think this is indeed a bug that should be fixed? Or is there an alternative way to write what I intended that I am missing?

Since this thread has gone stale, and all I got was suggestions to "write the code correctly" and recommendations that didn't actually work, I propose a "challenge":

Please provide the code that would generate this output, AND also paste the suggested code in the same forum message to demonstrate that it works. The code should not use HTML tags.

Please click "Preview" before submitting the message and verify that the output looks exactly like the "Output" section below. Since the forum seems to use the same Markdown parser as the documentation generator, this will help verifying that the solution works.

If no one manages to beat the "challenge" (and believe me, I tried), then I think it's reasonable to assume that I was right and Fossil's Markdown implementation has a bug, or is not able to properly implement nested lists within lists with paragraphs.

Example contest entry (cheating, since it uses HTML tags):

Code

This is a paragraph.

<ul>
<li>
<p>This is an item.</p>
<p>This list looks a-ok:</p>
<ul>
<li><p>Item 1</p></li>
<li><p>Item 2</p></li>
</ul>
<p>This list also looks good:</p>
<ul>
<li><p>Item 3</p></li>
<li><p>Item 4</p></li>
</ul>
</li>
</ul>

Output

This is a paragraph.

• This is an item.

  This list looks a-ok:

  • Item 1

  • Item 2

  This list also looks good:

  • Item 3

  • Item 4

Nobody? OK, then I think it is safe to assume that this is a bug.

Could some dev please look into this?

Can you check if the markdown-multiple-sublists branch address the problem for you?