[vmiklos]

I'm not sure about the current state, but the Python2 implementation was the original one, and the Ruby one came later.

So this statement:

> First off, it's a single implementation.

Is a bit misleading. It's more like there are no several flavors, like with markdown.

[fiddlosopher]

In fact, both claims are misleading. There are two implementations, and they implement distinct flavors with syntactic differences: https://consolelog.gitee.io/docs-asciidoctor/asciidoc-asciid... Markdown has a smaller flavors/implementations ratio!

[mbeex]

In fact, also this claim is wrong, because there are three :D

1. https://asciidoctor.org/

2. https://github.com/asciidoc-py/asciidoc-py

3. https://asciidoc3.org/

1 and 2 seem to hate 3 (see issue trackers / web sites of all three) and meanwhile probably also vice versa. The discussion was quickly dragged into the legal realm by 1 in particular, which very obviously dampened number 3's initial enthusiasm. Additionally, 2 describes itself somewhat prominently as a "legacy processor" for Python (technically correct in the current version, but legacy's meaning here is the relationship to the new Asciidoctor-specific constructs). At the same time it promises further development but nothing usable has come out of it so far.

As a Python programmer, I would simply like to see a pure Python3 toolchain. It is quite an absurd situation at this moment. For example, my blog is supporting Markdown and ReST natively (Pelican-based). For Asciidoc - my preferred language - Pelican has a plugin, supporting different Asciidoc processors, but only at the first glance. It has also to support KaTeX. This on the other hand is no problem for Pelican's native Markdown languages (simply another plugin), but the Asciidoc plugin is too high-level. It can only use Asciidoctor in this case, requiring Ruby's KaTeX gem as an extra dependency. This gem seems to be abandoned and has compatibility issues with newer Asciidoctor versions ...

2 is no option for its installation hell alone (Asciidoc3 is pure Python, simply a pip install). I don't know, if it is able to interact with KaTeX.

From what I can see, 3 would technically offer the best initial platform for further development as a package. Could be wrong, of course.