If the court v2 starts with its dispute IDs from 0 or 1, it's fine at the machine level. But when people are going to refer to "dispute no 153", there's a high risk that some confusion will occur between v1 and v2 dispute numbers.
PS: this risk of confusion already exists somewhat between the Mainnet and Gnosis chain KlerosLiquid.
Solution 1
Initialize KlerosCore to start counting the disputeIDs from an arbitrarily high number such as 10,000. That provides enough buffer until v2 goes live and replaces v1.
Pro: no coordination required against KlerosLiquid.
Con: leaves a gap of unused disputeIDs, so the disputeIDs are not a good indicator of the total number of disputes handled by the protocol. Should be fine because this assumption is already broken by the Gnosis chain KlerosLiquid.
Solution 2
Wait for KlerosLiquid to be frozen: no new disputes can be created at that point. Set the KlerosCore disputeID offset to the value of the last KlerosLiquid disputeID.
Pro: no gap in the range of disputeIDs used by the main Kleros deployment.
Con: more coordination needed. Assumes that KlerosCore will not handle any live dispute at all before KlerosLiquid is frozen, which may not be the case.
Solution 3
Make no change at the smart contract level. Encourage the frontends to display clearly an indicator of which arbitrator the disputeID is referring to (eg. a V1 Mainnet or Gnosis chain disputeID).
Pro: easier to adjust along the way, less coordination needed to build and deploy the smart contracts.
Con: the frontend has no obligation to follow any UX convention to display the disputeIDs in one way or another.
Problem
If the court v2 starts with its dispute IDs from 0 or 1, it's fine at the machine level. But when people are going to refer to "dispute no 153", there's a high risk that some confusion will occur between v1 and v2 dispute numbers.
PS: this risk of confusion already exists somewhat between the Mainnet and Gnosis chain KlerosLiquid.
Solution 1
Solution 2
Solution 3