T114051 is a problem. We need a meaningful table of contents as an object that we can work with, both in core and especially for extensions. This applies to parser functions, skins, and potentially anything introducing a new datamodel. As is, the only approach to working with a custom/modified table of contents is disable the normal one and then reconstruct it from parts, and often that doesn't work at all, forcing developers to simply implement a new one for the extension itself. Both of these are messy and inefficient, and result in inconsistencies and difficulty updating, with different structures and styles in every new one that likewise cannot be updated easily nor interacted with by other extensions.
It is also currently causing issues with caching due to how it handles i18n.
The question, of course, is what will the solution to this problem look like? Where will it be (it's currently scattered across the parser, the linker, and the skin backend, or some such)? What do we need from it to meet the needs of existing extensions, as well as potential new ones down the line? How do we not break core, and potentially all manner of skins that try to use it as is (bluesky, refreshed)?
Answering this, we can then establish a way forward.