Expanded Object Header and Flat Cache

I've been working through the expanded object code to try and get a
demonstration of it working with PostGIS (still having some problems,
but it's a learning experience). On an unrelated from, I noticed in
the array expanded code, that the array code is managing its own copy
of a cache of the flat representation and flat size,

https://github.com/postgres/postgres/blob/cf7dfbf2d6c5892747cd6fca399350d86c16f00f/src/backend/utils/adt/array_expanded.c#L247-L253

This seems like generic code, which any implementor is going to end up
copying (after seeing it, and seeing how often the flatten size
callback is being hit while debugging code, it seems like an obvious
next thing to add to my expanded representation, once I get things
working).

Why isn't caching the flat representation and size (and short
circuiting when the cache is already filled) part of the generic
functionality PgSQL provides? Should it be? I guess it would imply a
required function to dirty the EOH cache when changes are made to the
in-memory data, but that seems no worse as part of the generic API
than in all the client code.

P.