Nodes never automatically replace anything but the head block and only replace this with in a small window of time to account for 2 blocks being found 'at the same time'.
Wouldn't there be a non-negligible probability of a fork, if for example a small subset of nodes becomes isolated from the network and produces two blocks in a row?
A fundamental design principle of Bitcoin is that the network can recover automatically from a fork caused by a network split; everyone picks the chain with more blocks. Unless I'm missing something, your scheme always assumes the local fork is the correct one, and therefore any temporary split which causes a branch to get two blocks ahead becomes permanent.
This is a very good point and so I want to consider it carefully.
Using the shareholder voting analogy, we can easily resolve any dispute with a shareholder vote. Any block that has the majority of shareholder votes is automatically accepted as the best block. Lets forget CDD for a second, because it is an approximation that I think confuses what is really going on. When someone moves 100 BTS from block 60 to block 100, they are really casting 100 votes for each block (60,61,62..99). We can therefore see where CDD comes from, it is the total votes cast.
When it comes to resolving a fork, we do not care about 'longest chain' or even 'most CDD'.... we care about what percent of the shareholders are on each fork. Let give an example:
Suppose someone with 1 share, holds it for 1 year, and then creates a fork with 100,000 CDD. In reality there is only 1 share worth of support for that fork. The rest of the 99,999 CDD is voting for the global consensus on the first 99,999 blocks prior to the fork.
This significantly raises the bar for an attacker. Worst case, everyone on average moves their funds once per year. This means that the average votes cast per block is 40 BTS. To produce a chain that is 12 blocks longer (1 hour) would require 480 BTS to tie the honest chain. Once again this is worst case. I think we can assume that with mining, trading, etc, the average velocity will be some significant multiple of this. For the sake of argument i will assume 5x the minimal. This would increase the cost of the attack to 2500 BTS. Based upon the PTS price drop that would indicate a $25,000 attack and once this grows to be the size of Bitcoin the cost of the attack would be almost $2 million.
Now the attack isn't actually guaranteed even when an attacker has 2500 BTS. Honest nodes would recognize an attempted fork when there was no perceived loss of network connectivity. Someone with a lot at stake (say an exchange, a day trader, etc) would not want a fork under any circumstances if they could help it. These players could secure the network (and their recent trades) by moving a 1000 BTS per block to themselves. This would increase the cost of an attack significantly.
So we have a means to uniquely identify he best chain based not upon how many blocks, but how many votes it has. An attacker may get the lead for a sort period of time, but at any time honest nodes can simply vote for a better chain. Generally speaking the honest nodes will only want to vote for the chain they have seen until there is overwhelming evidence that the alternative chain has more support than any reasonable attacker would generate.
So when the client notices a fork, it notifies the user of yellow alert. If the fork has more votes then you are in red alert. You do not switch over to the fork until it has 5% (of total possible votes: share supply) more of the share holders on its side than your fork. When this happens, those in the know will quickly act to resolve the issue and all clients will move on.