If you define a replay attack as sending a tx to two different forks, and the tx being mined on both, then it is necessarily allowed, otherwise deep reorgs would not be possible, and they are possible, and have happened.
Network wide, one way to prevent this would be to tag a tx with the hash of a block which must be in the history of the block containing that tx. This way, you could tag your tx with a block which is on the fork you're spending on. The other fork could not mine that tx (assuming the miners there don't decide to start ignoring that rule). Such tagged hash information looks like it'd be prunable after a while.
If the network doesn't have any particular replay protection, and as a user you want to ensure your coins aren't replayed on another fork, I think moving your coins may not be enough for 100% certainty, as the other fork might also replay the tx which moved those coins, leaving your coins in the same state on both forks. However, it seems safe to assume the two chains will be different in their output set: in that case, it looks like moving your coins while referencing one fake output which does not exist on the other chain would work: the tx will not be valid on the other chain. I speculate that once the output set diverges, most transactions become automatically invalid on the other chain as they become more and more likely to include this-chain-only outputs as their fake outs.