EIP-1959 Valid ChainID opcode

EIPs
2

I have a few questions, but first I need to clarify something:
It seems this proposal requires that both sides of a contentious fork adopt different values from what occurred before the fork in order to be considered safe. Failure to do so would break the replay protection in at least one direction. Since there is currently no process for changing chain ID after a fork (such as the one @fulldecent suggested), such process cannot be assumed to occur, and thus this proposal is not safe by itself without additional application-level considerations (similar to EIP 1344). I think this should be made more clear under Rationale.

Anyways, here are my questions:

  1. How do you protect against a new message signed against an older chain ID? (Signed after the fork occurred)
  2. What kinds of application-level effects might occur if all chain IDs in the history are considered valid with differentiating based on time?
  3. Would it make more sense to emit what block height the chain ID fork occurred at for time-ordering of messages where chain ID update occurred?
  4. If the opcode returned a block height instead of a boolean, what happens when an invalid chain ID value is given? Does it throw? Return 0? Etc.
  5. If the opcode throws on invalid values, wouldn’t we need to add a new exception to the VM context? Wouldn’t it be easier in that scenario to use a standardize contract in this scenario? (Maybe a pre-compile)
  6. If the block height returns 0 for invalid values, then what does the current chain ID return for block height? Is it the height of when it started? When it finished being valid?
  7. If the current block height returns when it was valid from, what does chain ID 1 return? Implementation fork height of EIP 155? What about for other chain IDs for other chains?
  8. If the opcode returns the block height of when it finished being valid, what does the current block height return? The current block? How do we know that it’s the tip of the history of chain ID values?

I think this series of questioning summarizes my current concerns. I think they could largely be dealt with, but it requires a lot of nuanced thinking to get correct to implement this opcode contrary to EIP-1344, which requires only that the user of such an opcode be aware of and implement a simple strategy to handle many of these scenarios (if required by their application).