Hey Sylvain! Thanks for your question.
First, I want to clarify that there is no ratified spec as of yet. That's what this year will be about. What we have is the working definition of AsciiDoc as defined by Asciidoctor that was contributed as the starting point (the user's documentation). It is from that documentation (and the Asciidoctor implementation) we are going to define a spec.
> * Is the statement above a technical limitation of the current implementation, or is it part of the specs?
It is (and always has been) a technical imitation of AsciiDoc as it is defined today, though it's a limitation we hope the spec process can help us resolve (or clarify) as we proceed.
As I mentioned in the kickoff email (
https://www.eclipse.org/lists/asciidoc-lang-dev/msg00001.html), the first goal for the spec is to define the language as we know it today so we have a compatible starting point. That means accepting it's current limitations to a reasonable degree. But there may be room in that first version to have an alternative inline parsing mode that doesn't rely on regex-based substitution. Unfortunately, we won't know the full impact that will have on the ability to parse existing documents until we try it. And compatibility with existing documents is of the utmost importance for the first version of the spec.
> What about the other inline styles (Highlight, subscript, superscript, custom inline styles): Can they be mixed freely, both between them and with the emphasis styles, or are there some restrictions?
Due to the fact that AsciiDoc was originally designed using a regex-based substitutor to interpret inline markup, and that was emulated by Asciidoctor, inline parsing is (and always has been) notably limited. If we can get to a point where this limitation can be lifted by having a recursive inline parser, then that is definitely the step in the right direction.
What we're doing here is trying to make AsciiDoc more deterministic and thus easier to parse. But again, we have to think about existing content. We are not making a new markup language. We are refining the one we have in the best way we can. And if a prototype can demonstrate we can accomplish that, then it should help inform the spec process.
I hope that helps answer your question.
Best Regards,
-Dan
