Kind of. Can you use the interim state fork (original plus changes, not yet committed into a new immutable) as a "readable" type, the union of mutable and immutable variants? That would resolve choice dilemmas like the decision between mutable and immutable builders: keep the mutable where it is only used by the creating thread, materialise into an immutable when it needs to cross thread boundaries, fork where a thread needs to adapt a little and have all consumers typed to the readable version so that they can work with either, without requiring a new immutable.

> Can you use the interim state fork (original plus changes, not yet committed into a new immutable) as a "readable" type, the union of mutable and immutable variants?

Not really, not at a language semantics level - although in practice if you applied your current mutation to the original object, did something with the result, and then threw the "partially edited object" away, the JVM's escape analysis might catch that and never fully materialise the "partially edited object". Note that nothing is really mutable, not even your edit operations - you form your combined edit by composing together a bunch of smaller edits, but all those edits are immutable.