Reviving interlinked custom types produces wrong result

Problem

Reviving interlinked custom types, e.g. doubly linked list of custom objects, causes some fields to be undefined.
Example

The following happens:
during hydrating a: a's data refers to b, so b gets parsed:
during hydrating b: b's data refers to a, but a's data is marked as hydrated (even though it is unfinished yet), and the custom reviver is called with incomplete data.

Such cases cannot be revived via only a "constructor", for the same reason the doubly linked list cannot be created declaratively only (without assignments).

Workaround

This can be fixed by deferring "linking objects" to be done after parsing finishing.
But then another problem became clear: interlinks cause extra calls of revivers that break object identities, and the output is still not really correct. This can be fixed by introducing a cache of revived objects.
Thus, the workaround gets complicated.
Workaround example

Start by reproducing the interlinked custom-type case in the linked Svelte playground and trace hydration of a and b. Compare it with the linked workaround, focusing on deferred linking and revived-object caching; done means interlinked objects retain their fields and object identities without extra broken reviver calls.