> For a deployed image the stubbed ancestry might be much better indeed - and for that use case I wouldn't even retain 10 levels of history, but strip it down to a single version info per package. Just the bare info needed to pull in the full ancestry. (I also

The original plan for completing the circle was to allow the number of
levels to be specified as a preference that would not only affect
where it stubbed but also how far it bothered to look when doing
various MC operations.

Today, the only ancestry access in MCAncestry is pretty much just
allAncestorsDo: which ends up accessing the whole tree, again and
again and again, even though we almost NEVER need access all the way
back to version 1.  If we changed senders of allAncestorsDo: to
"recentAncestorsDo:" (respecting the preference), we could ensure the
Proxy would almost never be hit for read operations.  By defining the
size of what should be considered "recentHistory", like, something
between 10 and 100, the dev environments can be leaner too.
Production deployment script could set it to 0 to gain every last bit.

> would make re-instating the full version hierarchy an explicit action rather than a side effect, but we had that discussion already).

But then what should happen when the system got to the end of the
ancestry and reached the Proxy?