Could these extensions use ParserOutput's mechanism already? Not sure whether there's a benefit in using fields on Parser itself here.

In T324921#8460603, @TK-999 wrote:

Could these extensions use ParserOutput's mechanism already? Not sure whether there's a benefit in using fields on Parser itself here.

Certainly possible. This task was mostly filed as the followup to the attribute. If that works fine for the purposes, why not?

ParserOutput extension properties get stored in the parser cache, while storing data on the parser is typically for in-process caching or for coordinating between multiple calls to the magic word handler.

Change 921264 had a related patch set uploaded (by TK-999; author: TK-999):

[mediawiki/core@master] Introduce ParserOutput::{get,set}EphemeralExtensionData()

https://gerrit.wikimedia.org/r/921264

The proposed 'ephemeral data' patch is incompatible with T300979: Ensure ParserOutput can always be combined asynchronously/out-of-order. The data actually needs to make it into some form of storage (why not the parser cache) in order to allow (eventual) asynchronous fragment rendering to work. Adding properties to the Parser object is also not going to work with Parsoid, because in the transition period some parts of the page are going to be parsed with a LegacyParser object and other with a ParsoidParser object; there's no guarantee all wikitext on the page is going to get exactly the same parser object.

So let's look for other ways to do this.