Have I misunderstood the situation?
a replay attack only occurs when a transaction on one chain is also valid on the other chain. and since these forks are also copying the transaction history, the transaction output you are signing exists on both chains.
bitcoin and bitcoin-cash:
the method of signing is different since BCH has a different signhash byte so the signature hence the transaction that is valid on one chain is not valid on the other.
as a result you don't have to worry about anything. you can spend BCH first, or BTC first or simultaneously. it can not be replayed. the only thing to worry about is importing your key in a malicious software that can steal both coins from you.
bitcoin-cash and bitcoin-cash-sv!:
they never changed anything when they forked so a signature on BCH is valid on BSV so it can be replayed. as a result you have to manually split your coins which means first sending each coin to different addresses you control and if you succeeded then you can easily spend each token without worrying about replay attacks.
(for future references and future forks) an alternative way of protecting yourself against replay attacks for when you have no other option is this:
- it will be easier if one chain to be at least a little slower than the other.
1. create 2 different addresses.
2. create 2 different transactions spending the same transaction output(s) but sending to a different address created in step 1 (lets call then tx1 and tx2)
3. broadcast tx1 on chain1 and broadcast tx2 on chain 2. do it at the same time with least amount of delay. (automation can help a lot in this case)
4. wait for them to confirm.
4.1. if both transactions confirmed (tx1 on chain1 and tx2 on chain2) you have successfully split your coins so continue as you will.
4.2. if only one transaction confirms (tx1 on both chain1 and chain2 or tx2 on both chains) then go back to step 1 and repeat.
* i don't know hashrate of BCHSV but someone posted a picture once showing it has less blocks, so it may have lower hashrate and be slower. so it can work.
* step 2 works because nodes reject double spends. connecting to more nodes and broadcasting your tx to them makes it more likely to succeed.