Almost all macros would benefit, for example from a parameter called 'context' or 'root' which lets you indicate which page you want the macro to execute from.

{include:root=pagename}

(default parameter)

{toc:root=pagename}

(not a current parameters, but would be nice)

{metadata-report:root=pagename}

(current parameter)

Currently, all macros would have to re-implement this feature, and many do, and often give a different name. If confluence provided a $rootcontext variable to the macros, which was loaded from a standard 'root' or 'context' parameter, it would enforce standardization.

Other candidates for standardized 'global' parameters can be found on a page in the confluence extensions section, written by either Guy Fraser or David Peterson, but I couldn't find it right now. I'll list a few here:

pages - takes a well-written query language that allows macros to simply recieve a list of pages on which to perform their action (such as a $pages collection), but without each macro having to re-invent or re-implement a (different) query language. It could take:

• list of specific pages, or space:pages, with a standard delimiter ( ; ? )
• wildcards or regular expressions to indicate a group of pages by name
• perhaps keywords or symbols like @children, @parent of the current page
• space key designations
• as the 'parser' changes or becomes more sophisticated, existing macros woudl all benefit from these changes because they simply use the $pages collection.

labels - same as above: sets $pages to a set of pages that satify a 'label query', with () for nesting and some operators for and/or/not ( + , ! )

scope - descendents, ancestors, space, site, children, parent, self - specifies dynamic scope relative to the 'pages' option, or might be incorporated in the pages query language

query - uses the built in query language, i.e "title:My Page* AND author:james") to retrieve a set of pages for the macro's operation

style - specify a direct CSS style for this tag. These could then, in theory, be filterd by a per site configuration for all macros
css - specify a css class. likewise, could then be manipulated / translate site-wide for all macros

output - wiki / table / html / text (specified how output sould be rendered in page context after macro returns results)
input - wiki / table / html / text (specified how input should be rendered before passed to $body for macro plugin)

There are no doubt others that could be used. This request is for Atlassian to put in place the framework to support these 'global macro parameters'.

Thanks.