The linter extension can be leveraged for this functionality -- since the real use case seems to be for managing upgrades / deprecation, etc. Is there a reason not to go down that route?
Topic on Talk:Requests for comment/Parser function and tag tracking
Mostly a conceptual one - Linter tracks errors, and these aren't errors.
Right .. but, that is just a naming issue for the extension and special page? For example, for migrating templates to new syntax or for balanced usage, we need to track pages that use that. So, technically those are not errors, and we want to use the parsoid - linter combination. So, if these were renamed appropriately, would that address it?
To be clear, I am not saying you shouldn't create that new special page .. but, asking the question if there is a way to consolidate these where possible.
Or, to put it differently, barring that deprecation / maintenance use case, what value is there in knowing what pages use which tags? It just seems to create another SpecialPage that is mostly not useful day-to-day. Aggregate statistics followed by linter categories would probably do the trick in the common case?
> what value is there in knowing what pages use which tags? It just seems to create another SpecialPage that is mostly not useful day-to-day.
It is valuable to track if certain tags are used in certain namespaces. For instance, despite being discouraged, even on big wikis such as english wikipedia there are users adding stuff like {{#if within the main namespace. There are also use-cases that aren't covered here, for example, tracking whether a new page has <ref> / <references>. If available in page props this could probably be simple to add to recentchanges / special:newpages, etc. Currently, pagetriage seems to use a hacky approach of parsing the whole page, and can't detect those included by modules or templates.
It seems like this is case where one should have the best of both worlds. Track tags using page props, and use a white list of parser functions / tag functions in the linter extension that could be nuked ( e.g. easytimeline -.> ext:graph).
Of course Special:PagesWithProp would still need several improvements. Currently it can't filter namespaces, nor can it display more than 10000 items. Its items are also not indexed by the search engine (unlike tracking categories). Generally speaking though, if page props is improved then tracking categories should probably be fully removed from mediawiki itself and its functionality added to pageswithprops / linter . Rather duplicating functionality, e.g. "category:pages with graph" <-> graph_specs (page props), category:pages with self closing tags< -> self closed tags(linter).