His post is mostly FUD because he is pushing an Anti-Gavin agenda and myopically assumes himself to be on the winning side rather than looking at the system as a whole.
If the world was beautiful and clean a fork would instantly separate the networks, so if you had N coins on Bitcoin, you'd now have N on BitcoinA and N on BitcoinB. Someone would then quickly put up an exchange site that let you trade BitcoinA for BitcoinB, so you could sell the side you think will lose and buy the other, or choose nothing, in which case you'd end up unaffected (that is, still with N coins) once one fork dwindled to nothing.
But the reality is more complicated and you'd need careful code analysis and probably simulation to figure it out. Yes you have N coins on both forks but the problem is that when you issue a transaction, it will be picked up by BOTH forks. You can't spend on just one fork! Your txn is valid on both, and even if you figure out how to "trigger" it on just one fork, the receiver could reissue it on the other thereby "stealing" your coins on the other fork.
But in theory the receiver would not have to; pending transactions won't be purged, so BitcoinA and BitcoinB would process the same transactions on different blockchains forever, keeping the forks in sync. In practice, the smaller blockchain would probably drop some pending transactions eventually, resulting in a slow divergence. Could you force this divergence? It would take careful code analysis to figure out a way, but it would certainly be messy and probability based. But eventually when transactions increase to consistently exceed the capacity of blocks in the smaller chain it would chew up all RAM and crash the code today (as per Mike Hearn's analysis). But if patches were added clean that up, then finally you'd be able to pretty reliably target a transaction to a particular fork (by giving a txn fee too low for the fork with smaller blocks, for example). Once you get the first single-fork transaction, you can now spend those coins independently because they are on different addresses on different forks.
At that point, both forks would see and attempt to apply each other's transactions, so you end up with lots of spends from "invalid" addresses "spamming" the network. This would be a huge mess for statistics, visibility and analysis sites like blockchain.info.
Rather then risk the mess above, it would probably be better to add a "version" field to the transactions (and every other protocol message), change this version field EVEN if that protocol message didn't actually change, and have clients ignore messages of the wrong version. Write your new clients to rev the version field once a particular block # is mined. This would get you a clean separation.