Some keys are constant by the nature of their purpose. Others change by the nature of their purpose. Objects normally become constant when holders of keys sufficient to change them, refrain from doing so.

Bugs

It may be discovered that the code defining the implementation of a key is erroneous and it would be possible, in principle, to cause the key to begin "doing the right thing" whereas it had possibly not always done so in the past. Alas computer experience tells us two things about this:
There may not be universal understanding about the purpose of the object and some of the object's users may depend on the object working as it does rather than as "it should".

Too often the fix makes the object fail in ways unrelated to the intent of the fixer. {Programming is error prone. Even fixing bugs is error prone.}

The object user may thus need the ability to control the degree to which he must begin to depend on the "fix".

Factories, binders and VCSK segments form themselves into a tree of objects with related values. The parent is always older than the progeny. When the parent dies the progeny die. The only variable objects in these trees are at leaves.

This behavior is efficient when the trees are short. It is inefficient of storage when many generations occur with no need for the intermediate generations.

More concisely: this scheme is efficient when a derived value is not needed longer than the base value.

Instances of near values

Variations of a program:
Before and after bug fixes

With and without extra charge features

For different environments

Variations of a data base:
Before and after a particular transaction

A checkpointed state vs. current state

Simulation results:
Outputs that (of course) depend on input parameters

(What else is there in a computer?)