Sometime, we have a need to store information other than ParserOutput in association with page output. So far, the preferred way of doing this is to store this data inside the ParserOutput (as a page property or as extension data). While this works well for many cases, there may be situations where this is undesirable:

• The information is big, and not always needed along with the normal ParserOutput, causing unnecessary overhead (e.g. TemplateData, see T266200).
• The information is not immediately available after rendering, but may be generated by a background job (e.g. Wikibase constraint reports, see T214362)
• The information may change under conditions that would not cause the ParserOutput to be regenerated
• The desired guarantees for availability of the cached content are different from the requirements for the primary content (e.g. quicker expiry to preserve storage space, or local in-memory storage to improve speed)

Since the introduction of ParserCacheFactory, we can easily create separate parser cache instances, and configure them differently according to the needs of a certain kind of output. However, the code still requires all cached output to use the ParserOutput class. That is the last remaining obstacle that keeps us from using ParserCache in a more flexible way.