As the old saying goes, " those who don't learn from history are doomed to repeat it".
The issue here is that attempting to build a hack on top of a hack like this is likely to fail, for various reasons:
- Different design in different wikis
- Templates such as these are themselves hacks
- Page issues are metadata - no different than interwiki links
Wikia seemed to have tried a similar thing, with an extension called Flags. It was more sensible than this approach, and provided a graphical interface to set certain page issues, some for readers, and other to editors. The primary reason it probably failed is exactly due to an over reliance on templates (it too depended on templates). Templates in these cases aren't used because they are great. They are simply a desperate tool borne out of the fact that Mediawiki / Wikimedia has no annotation mechanism for either editors or readers. So their solution seemed to have been the greater evil of bombarding everyone with these monstrosities, e.g. many page issues are 100% irrelevant to readers, but they may be to editors.
A more sensible approach would be to first develop a way to way to identify these in a structured manner, e.g. TemplateData, thereby identifying templates by what their primary output (similar to https://phabricator.wikimedia.org/T165053). Then to develop a sensible interface that doesn't rely on templates to create structured issues like these, and let editors adopt them, perhaps with a heuristic tool that migrates the data from templates to the structured system. Finally, once implemented, simply hide all templates that look like page issues from mobile devices.
One obvious benefit will be the ability to do targeted updates whenever a specific element of the structure of the page issue changes, rather than the messy and horrible update to all pages that include it.
Of course, the sensible approach will likely be met with editor resistance. Resistance to chance is human nature...