Pass-by-reference UDTs and volatility

Hello,

I am working on an extension which defines a number of user-defined
functions which will operate on a common, custom data type to perform a
pipeline of transformations (the data type is the IN/OUT parameter for all
of the functions), eventually being supplied to a sink function which takes
the data type as input and produces tuple(s) as output. A source function
will produce the initial instance of the data type and feed it to the head
of the pipeline. As such, the data type only ever exists in memory and is
never intended to be used as a column of a table or persisted to disk.

What I would really like is something like the "internal" pseudo-type that
can be used to define the functions, but is not allowed to be used as a
column type in a table. However, since these functions must be callable
from a user context, "internal" will not work. I'm not that concerned with
users trying to use the data type in table DDL as they can simply be
instructed not to in documentation (and suffer the consequences of their
actions if they don't read the fine manual). However, in chapter 35.9 of
the Postgres docs, there is this warning:

"Never modify the contents of a pass-by-reference input value. If you do so
you are likely to corrupt on-disk data, since the pointer you are given
might point directly into a disk buffer. The sole exception to this rule is
explained in Section 35.10."

If the UDTs the extension defines are the sole producer/consumer of the
data type and are consistent in the way they manipulate the in-memory data
structure for the type, can the above rule be safely ignored? Or could the
backend do something like try to persist intermediate return values from
functions to temporary hard storage as it proceeds with execution of a
query plan?

Thanks.