I haven't paid much attention to this fork, there are some details I'd like to get clarified.
I'm not sure, but I believe this is actually a "three-sponged fork". There is the nChain-team (led by Craigh "maybe I'm satoshi" Wright) doing a hardfork in one direction and the BitcoinABC/BitMain team doing a hardfork in another direction - but the fork also has a middle sponge - the "status quo"-option, continue mining with software not containing any updates. Probably the third option is insignificant, probably nobody is going to mine the status-quo-chain, but nevertheless it's an option (and also the reason why the "fork"-term is being used for software upgrades at all).
Is there any kind of "replay protection" in this fork? (I dislike that phrasing - the thing is, if a transaction is valid on all forks of the chain, you're sending away all three currencies when creating a transaction. At the other hand, if one of the forks defines a new transaction format then there will be a "clean" split into two new tokens. "Replay protection" comes at a great cost - the client software needs to be updated to support the chain having "replay protection".
Which leads us over to the next question - what clients does most people use, and what kind of forking support does the clients have? I'm aware of three clients, though probably more exists - it's the bitcoin.com-wallet (a software fork of the copay wallet), it's electron-cash (a fork of electrum) and mycelium (with the bitcoin-cash plugin installed).
Those are light wallets... they do not enforce consensus rules. According to this post by Edge Wallet the three full node implementations are ABC, SV, and Unlimited and are all planning seemingly incompatible hard forks.
I don't think any chain is implementing replay protection (a backwards incompatible transaction syntax). Hence things could be a real mess, but I'm guessing the economic majority is heavily behind ABC, so the SV token will have little value.
Yes, I forgot ... the full node implementations are also wallets - though in the big-blockers point of view, there is little point in running a full node, unless one either is doing mining or have strong business reasons for it. Ordinary users should do their transactions through light wallets.
Meaning that the light wallets by default will "see" the transactions on the chain with most mining power, but send transactions that are valid on all chains.
I honestly have no idea what light clients will see. I guess it depends from where they pull their data.
As for transactions, a basic transaction will be valid on all chains, but when you move between your wallets nobody has an incentive to replay that, but it might still be replayed. But when you put one of the 'new' opcodes that will not be valid on all the chains. So there is a clear way to separate the coins.
Note that when you send coins on the SV chain to a new address, then your coins on BCH are protected when you send them. But when you send your SV coins to a merchant, the merchant can still replay your transaction. All they need to do is replay moving the BCH coins to your SV address and then repaying from there. So to be safe all coins on all chains need to go to a new different address.
There are indeed 3 forks, plus the ability to mine the old. Bitcoin ABC and Bitcoin SV are not compatible in the chain. Bitcoin unlimited should be compatible with both. Not forking is compatible with neither.
But in practice it may be a lot messier. As long as the new opcodes are not used and there are no huge blocks, everyone is compatible with everyone. Then if a new opcode is used on a low hash-power chain that block may end up being orphaned.
Will be exciting to see how this plays out.