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.
That is yet a different concept, where it doesn't include the full history, but without a partial clone it still pulls the entire tree for the head commit.
