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.

aXML allows for 2 types of non-standard bracket delimiters, ( ) and 
[ ],  Which mean respectively, process this tag before all others, and
+ process this tag after all others.
[download]

Please don't take it as a personal offense, but it this a wise choice to begin with? Personally I see problems with it:

1. clashes with parens and squares in the text, as already pointed out by graff;
2. creation of something that is somewhat like XML, but in fact is not.

Now, as far as the second point goes, it if were compellingly necessary, I don't think it would be a problem, although it would still leave you with the need to invent a wheel only slightly different from those that are already available, and thus to reinvent many wheels. Or to take existing tools, understand how they work and modify them to suit your needs, which would save you considerable time and give you more guarantees of doing the Right Thing™ but would still be less trivial than one may naively expect. Even without that, the approach is somewhat inelegant. XML is not exactly "simple", and I'm not really a big fan of it, but it has an elegance of its own. Having three different breeds of tags strikes me as breaking that. If the tags still have to nest correctly, you could achieve the same thing with attributes. Granted, it would be more verbose, but since you're dealing with "a sort of XML" anyway, that should not be a concern. Otherwise you would be using a lwml instead. If you go with attributes, then you will have regular XML and you could use one out of many already existing tools to parse XML.