This is not simpler or nicer (per the current submission title) or better or cleaner (per the linked article). Well, it may be simpler in some regards if it lacks Markdown’s HTML basis (source of all kinds of problems but also of its popularity). Oh, and definitely simpler in being limited to two levels of headings (read: document title plus one level of heading). But nicer, better, cleaner? It seems to be determinedly different in a variety of capricious ways that are not obviously superior, and are sometimes obviously inferior. And only supporting one level of heading after the document title is… a choice; and not one I’m willing to consider better or cleaner.—⁂—
Code blocks are indented by six spaces. Oddly specific. Four spaces or one tab I could understand, even two or eight spaces have some precedent, but six spaces?
Combining that with treating “### ” as special… very odd.
—⁂—
Link syntax is possibly even worse than Markdown’s.
Now Markdown’s is terrible: people mix up the square brackets and parentheses frequently, the fact that the href is next to the delimited text rather than inside (e.g. [text <href>] or [text|href]) is dubious, and it uses as its closing delimiter the right parenthesis which doesn’t get escaped in URLs <https://url.spec.whatwg.org/#url-code-points> so that you have to add an extra step after normal URL serialisation, { '(' → %28, ')' → %29 }, for general correctness.
But Shrimple’s? The idea of merging hrefs with footnotes is definitely appealing, but the way it’s been done is hard to read and quite unmanageable. The link is essentially delimited by a "-> " prefix and a "[N]" suffix. Tough to read, though syntax highlighting may make it more bearable. But really, paired delimiters are generally safer. In Markdown, it would have been a "[" prefix and a "][N]" suffix, and that would have been nicer.
Then the URLs (as text, not linked) remain at the end of the document, devoid of context.
And you can only use numbers, not names. And to be frank, inline hrefs are better a significant fraction of the time.
Footnotes are a bad idea in general: you have to go all the way to the end of the document to resolve them, then find your way back. By contrast, in languages like Markdown and reStructuredText you can define your links closer to where they’re used, if you wish.
reStructuredText_ lets you link a single word with a trailing underscore.
Multi-word link targets need `backtick delimition`_.
In either form, double the underscore for an anonymous link__,
which you can place after the paragraph.
That might sometimes be neater than using an `inline reference <https://example.com>`_.
__ https://example.com/
.. _reStructuredText: https://docutils.sourceforge.io/rst.html
.. _backtick delimition: https://docutils.sourceforge.io/docs/user/rst/quickref.html#hyperlink-targets
I also think that notes sources should be spanned: mark which words the footnote applies to. But that sort of thing is going beyond what Markdown covers.(Content-wise: looking at the footnotes, I see two orphaned footnotes, and one of them seems to have bad HTML escaping done to it, > becomes &rt; which is invalid; where I would have expected that -> to become a link.)
—⁂—
Lists: requiring two-space indentation is bizarre. For bullets, it can be nice to match four-space block indentation, and that’s how I’ve tended to write things in my own lightweight markup language (LML), but then for numbers you want one or zero spaces to keep up that concept. In the end, it’s just… why?
> Subsequent items may be numbered normally (unlike Markdown, where they all have to be "1").
That’s flat-out wrong about Markdown.
> Numbers don't have to be consequtive, but they will be normalized to be consequtive. It just werks!
Yuck, yuck, yuck. That’s what Markdown does, and I hate it. If I wrote 44, I meant 44. If you really want to, have tooling that detects sequence breaks and warns “did you actually mean 44?”, but changing what the user clearly wrote is nasty.
—⁂—
Parse and render dictionaries: seems a very specific feature that is unlikely to compose well. The basic concept can definitely be useful, but I don’t think it’s exposed well.