Description
For some reason, it seems that if certain dependencies of a codebase definition happen to be in a loaded scratch file, the codebase definition will have a different runtime hash calculated for it. For instance, in the @unison/json library, we have:
tryUnconsText txt = toEither do unconsTextOrThrow txt
If the exact definition of unconsTextOrThrow has previously been loaded in a scratch file, then tryUnconsText will have a different hash than if you start a fresh session and ask for the hash of tryUnconsText.
As a guess, it may be that unconsTextOrThrow is left out of the definitions to be rehashed and the rehash reference is not pre-substituted into tryUnconsText. This would mean that the hash of tryUnconsText is calculated using the codebase hash, not its appropriate runtime hash. The code does not try to check this, as it is just substituting Reference values for one another.
A consequence of this is that it can poison the builtin replacement code, making the optimized builtin not get substituted for the unison code, and causing slower performance.