Hi, I'm currently using 2 extensions, GeoData and Maps, both of which define the #coordinates parser function, and Maps seems to take priority over GeoData when using the function in pages. Ideally I would be able to write something like #Maps.coordinates or #GeoData.coordinates to avoid this issue.
Would this feature possible to implement in this (the ParserFunctions) extension?
The ParserFunctions project is specifically about Extension:ParserFunctions, which only defines the #if, #ifeq, #switch, etc. parser functions; the extension (and thus its project) doesn't have anything to do with parser functions defined by other extensions. The correct project for a cross-extension request is MediaWiki-extensions-General, which I have changed this task to.
In this particular case, the recommended course of action would be to get one or both extensions to add a unique alias for the #coordinates parser function, and possibly to automatically detect when they're both installed and have some sort of compatibility code for that situation. Until that happens (assuming it ever does), I suspect that the order the extensions are defined in your LocalSettings.php is what determines which one takes precedence; if you need the GeoData function most of the time, try swapping the order they're defined in.
More generally, it may be worth creating some sort of parser function registry, similar to Extension default namespaces, to help extension developers avoid these sorts of collisions in the future.
Cross-link to https://github.com/JeroenDeDauw/Maps/issues/530, which is the issue on extension Maps.
Specifically, it was added in Maps 7.1 a parameter $egMapsEnableCoordinateFunction to deactivate the parser hook #coordinates from Maps, as a workaround in this case, but this task remains valid to give a better answer than deactivating one of the two conflicting parser hooks.
A parser function registry is a good idea imho (parser functions and magic words btw).
Also behavior switches and tags. Though I don't know if all of these should be on a single page, or if they should be separated (and if they should be separated, exactly how that separation should be handled).
There already is effectively a parser function registry, it's just in Parser itself. I'm not really sure we should allow for multiple extensions defining the same function. One of the benefits of wikitext is the portability, and if e.g. #coordinates means two different things depending what extension you have installed, then that's not great.
Also, if we want alternative names (e.g. #coordinates_maps and #coordinates_geodata), then the extensions can simply register those names as well.
Maybe we should change the behavior of setFunctionHook to throw an exception if it's going to override something unless explicitly told to (Parser::SFH_OVERRIDE)? I'm not sure the breaking behavior change would be worth it.
The point to the registry would be so extension authors could see whether a name they're thinking about using has already been used by some other extension. A secondary benefit would be allowing readers to easily find the extension that adds a particular function, given this information isn't really exposed by MediaWiki itself (maybe the API has this information, but most editors don't know how to use the API). As I said above, this would be similar to the Extension default namespaces page.