EIP-3675: Upgrade consensus to Proof-of-Stake

EIPs EIPs core
,
7

EIP-2124 fork identifier section in the specification currently has the following statement:

Starting with TRANSITION_POS_BLOCK that has block number N, nodes MUST update FORK_HASH by appending uint64(N) to the sequence of hashes used to calculate FORK_HASH as per EIP-2124.
FORK_NEXT can remain 0 after the transition.

Suppose the local node is syncing and haven’t reached the TRANSITION_POS_BLOCK yet while the transition has already happened in the network and the TRANSITION_POS_BLOCK is known to the remote peer the node tries to connect to. The remote peer has updated its FORK_HASH with TRANSITION_POS_BLOCK according to the aforementioned statement, and, thus, local node will disconnect the peer because of incompatible FORK_HASH values.

A straightforward way to prevent the network from falling apart because of uncertainty around TRANSITION_POS_BLOCK is to keep FORK_HASH unaffected by the Merge. The question is: can and should we do better?