Okay... I think you're getting ahead of yourself a bit with the embedding and ordering. First off, your using "special" tag delimiters (parens and square brackets) that have some greater-than-zero probability of showing up as actual text data in a given chunk of typical content.

How are you going to know (decide) which parens (brackets) are wrapped around your special "axml" symbols, and which are (normal) chunks of actual text data? And what's going to happen when the text content itself -- independent of any added axml markup -- contains unbalanced parens (which happens more than you might want to admit.

Aren't you running a risk, of indeterminate but non-zero probability, that "name space" collisions will occur? That is, the names being assigned to your special replacement placeholders are going to have to be distinct from whatever might occur as actual data (e.g. tokens that might occur between parens or square brackets).

And that's all distinct from the problem of the complexity imposed on the content when you start talking about embedding/nesting replacement strings, and forcing precedence relations based on parens vs. square brackets vs. angle brackets. I can't get my head all the way around it, but I can foresee clashes in store... an angle-bracket style directive inside a paren-style directive, etc.

The task you're trying to accomplish with this mechanism can't be all that complicated. It's not just the fact that it never would be; I think it's also a matter that if it were that complicated, you'd need a different mechanism to make the control of it comprehensible to humans.