One of the things that has been high on my mind since very soon after I studied Bitcoin was what happens in the case of a code fork? That can actually be noted in my post on the aformentioned thread in fact.
Because I feel it likely that the existing blockchain will form a value core for whatever fork becomes dominant, I figure that I'll just wait it out. Nobody can transfer value without a secret key, and a fork which makes that possible will probably not become the successful one. (Though it is more possible that the successful fork will force a value transfer which would suck.)
The main problem is that sitting on BTC without spending it is quite inconsistent with an _exchange_ currency. Bitcoin being couched as such will lose a lot of credibility and confidence in the case of an otherwise not terribly threatening event such as a code fork.
As of a day or two when I thought of it, I like to say "Bitcoin is in it's infancy...it hasn't even hit it's first code/core team fork yet."
Just to clearify...
What I meant is that changing the current protocol in a non compatible way will force a fork, and the fork will win no doubt.
If it is possible to make a change on top of the current protocol that say removes anonymity, a fork is needed, and should technically work side by side with the new version.
A fork that is not backward compatible will never work imo.
Ya, I am thinking more along the lines of a disagreement and fracture of the development team, or a new development team which the bulk of the users consider to represent their interests more. Say, for instance, there was a dis-agreement about whether to change the proof-of-work algorithm or something like that. Ultimately, a protocol change implies a codebase change though. Being open-source the decision is really made mostly by the users, and the makeup of the userbase is subject to shift around over time for various reasons.