Perhaps a better way of putting it would be that wrapping a list in a style like this will break the list rather than drop it to pure text. It isn’t something that has a graceful fallback, and remnants of list formatting may remain (largely nonfunctional in the editor)—in this case if one compiled your sample to RTF and opened it in Word they would probably get double-bullets since enough of the list remains to declare it, but the bullet structure itself that we can see in Scrivener is no longer a part of the syntax.
That’s a good point, I omitted an important ingredient in my suggestion. The above is only a problem if one doesn’t designate their markup. The system was designed for this kind of blending of writing methods, but it needs human guidance to pull it off since it doesn’t have a full parser built-in. Simply wrapping the replacement code in Preserve Formatting (in conjunction with the Treat “Preserve Formatting” as raw markup compile option) or a style set up for raw markup is the correct approach—same thing you would need to do if you wanted to blend raw HTML into something intended for ePub output for example. The compiler needs to be told what it should leave alone.
Original text in Scrivener, using Preserve Formatting.
Here is the intermediary MultiMarkdown output:
<div class="info">
* This is an **Apple** *list*.
* It contains inline styles like `code spans`.
* It contains [scene b][] document links.
* And [regular hyperlinks](https://www.literatureandlatte.com/).
* And that is that.
</div>
And the HTML5 converted result:
<div class="info">
<ul>
<li>This is an <strong>Apple</strong> <em>list</em>.</li>
<li>It contains inline styles like <code>code spans</code>.
<ul>
<li>It contains <a href="#sceneb">scene b</a> document links.</li>
<li>And <a href="https://www.literatureandlatte.com/">regular hyperlinks</a>.</li>
</ul>
</li>
<li>And that is that.</li>
</ul>
</div>
Pros and cons: if one intends to also use Scrivener’s standard RTF outputs as well, then the best approach is to use styles instead of Preserve Formatting. The former have the optional capability of deleting marked text on a per Format basis. Thus one can include special instructions for Markdown outputs, omit them in PDF, or include secondary instructions for ebooks that are omitted for Markdown and PDF. Styles are a way of creating agile source materials. For simple cases though, PF is going to be more straightforward and involve less setup (you don’t even have to make a custom format).
As an aside, you can have lists and tables converted to Markdown along with standard Markdown text, if that is all you need (I use that option for some projects).