The current renderer has the problem that there can always be only one renderer, i.e. if a plugin wants to change the output of a certain syntax it either needs to replace the syntax or be a renderer plugin but no two renderer plugins can be active at the same time. For adding (additional) metadata for core syntax elements the same problem exists, the metadata renderer can't be replaced at all but plugins can scan the instructions themselves (but are then missing plugins that are dynamically adding additional instructions).

There could be a list of handlers for each renderer function. During the renderer setup plugins would have the possibility to modify this list, i.e. to add or remove handlers. Handlers of a certain instruction would be called like current syntax plugin with the renderer object (see below) as first parameter. The list of renderers would be automatically populated with the current renderer functions. A plugin could choose to be added to every renderer (e.g. because it just modifies some content or some parameters) or just to be added to certain renderers.

Additionally, a new type of objects could be introduced: doc writers. Similar to call writers in the parsing process they would collect the renderer output. This would allow syntax plugins to post-process the output of other renderer functions without having to mess around with the doc string.

It should also be possible for renderer functions to modify the parameters that are passed to other renderer functions and renderer functions should have priorities.

The renderer functions are already called by their name as string, I don't think that adding a lookup in a two-dimensional array (first dimension instruction name, second handler list) where the second array is usually very small (or could also be replaced by the string itself) will have a large impact but this should of course be tested.

The current renderer class could be replaced by a compatibility wrapper that uses __call for calling the handlers for all instructions. If this is too slow every instruction could be implemented with an explicit function that calls the registered handlers for this instruction. The doc writers could also be accessed using the __get and __set-functions for the current doc variable. The renderer object would also store the various meta information (and the metadata in the case of the metadata renderer).

Existing renderer plugins could still work as they currently do.

• the include plugin could record the current section/header level as the page is rendered (and doesn't need to scan instructions in advance) and could still ignore headers inside included pages
• the include plugin could correct links on the fly by changing the parameters for the internallink handler instead of modifying the instructions in advance
• plugins like purplenumber, xbr, … can work together
• plugins that want to replace core syntax like various list plugins don't need to break plugins that rely on instructions like the navi plugin (e.g. they override the syntax, add the default instruction in addition to own instruction but remove the handler of the default instruction)