You are right. This is something what could be a real problem. If the same chain hopping happens like with Bitcoin Cash, you can run in exactly your described situation.
I guess the only secure way would be just to wait until both chains have a stable hash rate to minimize this risk.
Nevertheless I also would prefere that the Segwit2x devs implement a replay protection. Even if the timelock trick would work 100%, with the current clients it is too complicated to do for the average user.
It is not even about the stable hashrate. These rapid increases in the mempool come out of nowhere. If they all of a sudden come out on the logger chain, you are stuck and the other chain will catch up by the time your transaction is confirmed in the longer chain. So this problem isn't just going to go away in few weeks, it is there forever. These two chains can't safely coexist. Using one means that you completely ignore the other as it doesn't exist.
Just want to add something I haven't thought before.
The nLocktime way does work, as long as you transfer your coins to one of your own addresses (what you actually do, when you want to split them).
So even if the nLocktime does not work correctly the first time, and the transaction got replayed, you can try again and again until it worked, just from the new address.
In this case you would not risk to lose your coins, but it might take long and could be expensive depending on how many transactions you need to finally split your coins on the networks.
But that's only needed in case of no replay protection. I still hope they work on something like this.
Some people claim, that the Segwit2X developers are working on the client - just not on github, but internally. Hopefully this is true and they also think about a replay protection.
Nevertheless, hiding what you are doing in an open source project is not something that generates trust...