Superficially, yes, that's correct. However, on a deeper level *maybe* it misses something. Specifically, this problem wasn't found by automated testing. Rather, it was found by noticing the automated testing was finding problems with nested extension calls, and then suspecting that there was a deeper problem with the interaction between nested extension calls. The fact that such a problem was then found by hand leads me to wonder whether this hypothesis is correct. In other words, this seems like it *might* be systemic in nested extension calls, rather than a one-off. For example, suppose a site has extensions A and B installed. Now suppose a user does something like this: <a><b arg="something"></a> (i.e. Makes a nested call to extension B inside extension A.) or this: <a><a arg="something"></a> (i.e. makes a nested call to extension A instead extension A.) Calls to extensions inside wiki text are special, and from the Parser output it's clear they're treated specially, in that they seem to have different precedence. Currently extension A has to do lots of checking of the input to prevent this kind of thing from being a problem. Example: http://nickj.org/MediaWiki/Parser26 which abused a call to the ref extension inside a call to the ref extension. Your fix is here: http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-May/015379.html ; But the potentially worrying bit was that it only addresses that specific extension. So that was Ref + Ref. Besides this problem, there are others: http://nickj.org/MediaWiki/Parser31 , which is Inputbox + Math. http://nickj.org/MediaWiki/Parser28-variant1 , which is Sort + Math. And of course this one, which is Sort + something. *Maybe* (and this goes back to the thing of formally specifying what's allowed in wiki text) nested calls to extensions should be ignored by the parser. Or, failing that, maybe the inner call should have to complete, and then the outer should be called - whereas I suspect *maybe* sometimes the outer is called first, and then the inner is called second, which potentially is where some of these things are coming from. Either option would allow extension authors have to worry less about bad input (by making it more the Parser's problem than the extension's problem). Of course, I could be wrong. All the best, Nick.