A couple of thoughts:

1. I doubt it’s possible to implement “unfreeze” operation due to the inherent races between the update transaction and potential concurrent fast-path reading transactions.
2. This problem seems similar to the DenyListV2, for which @tnowacki has implemented a bespoke “PerEpochImmutable” solution: we could generalize the "PerEpochImmutable" objects for general-purpose usage in future (though no one is working on it right now), and that would provide a way for the Version and Config objects to be used in the fast path transaction with a caveat that their updates would be visible in the next epoch only.
3. Note that since Mysticeti rollout the latency benefits of by-passing consensus have been significantly reduced to 250-350 ms. The usage of owned objects in the transactions that go through consensus might turn out to be a decent long-term solution for as long as the shared objects are not congested via concurrent mutations.