We almost certainly wouldn’t support Markdown in Zotero and wouldn’t want Markdown parsed by the processor. We’ve always planned to just use a simple rich-text editor, as @Sebastian_Karcher says. It’s not hard, and Markdown isn’t something most of our users would know or expect.
The point here, I would think, is to have a limited, defined set of supported formatting options that all clients know they can use. HTML-emitting rich-text editors make that easy. If a citation processor supported Markdown as input, that would make it much less clear what output you would get for given input. If there’s a > at the beginning of a title, is that going to turn into a blockquote? Is it going to be stripped? Passed through as a literal? If I use arbitrary HTML, is that going to remain as raw HTML because it’s passed through by the citation processor’s Markdown processor? Will consumers of the generated HTML need to sanitize it because they won’t know what tags it might contain?
I think if a client wants to support Markdown, it should do so itself and pass on the HTML subset to the processor. Note that this actually allows clients to decide what output they want to support, because they can parse the processor’s HTML output as Markdown. If the processor took Markdown as input, that decision would be left to the processor, forcing the client to escape any Markdown it wanted to preserve that might otherwise be stripped by the processor’s implementation. And since clients likely want to display rendered values themselves separate from citation processing — e.g., in the items list in Zotero — they would need to bundle a Markdown processor anyway, and they might handle it differently from the processor.
Math support is an occasional request by Zotero users, and that, too, should be handled by the client, using whatever interface it thinks would work best for its users, and handling any rendering itself. That’s not for the processor to dictate.
I will note that citeproc-js’s micro-HTML approach is a bit unorthodox, in that it treats other angled-bracket tags as raw text, not HTML markup. But the benefit of that approach is that it avoids all the problems of sanitization I mention above. Nothing is stripped unexpectedly — including unpredictable input from all sorts of data sources — and you can trust that the output HTML is safe to display, because the only unencoded output is generated by the processor itself. (It does mean that when Zotero switches to a rich-text editor for titles, we’ll need to look for those defined tags and convert everything else to encoded text before rendering as HTML internally, but fortunately that’s easy.)