If there are two independent Bitcoin clients with roughly equal market share, then the protocol becomes the intersection of supported features on both clients. The protocol is no longer singularly developed ahead of the reference implementation.
@NotATether: You see, I think that's a good thing. With N independent implementations and a reasonable distribution of hashing power between them, then as N gets bigger that "intersection" means a more bug-resilient network.
Of course, it also means a network that is much harder to implement changes on, but I'm not convinced that Bitcoin should be messed with all that often anyway. Personally, I would prefer it if Bitcoin was even more conservative about protocol changes than it already is.
It will be possible for some feature to be added to the protocol (by people who also happen to be devs of the first clients), but the second client torpedoes the feature by not implementing it. This is the exact hell that is facing LN at this very moment.
@NotATether: Maybe I'm a masochist, but I think that's a good thing too. It's painful, but that's how "real" distributed consensus should work, IMHO.
The whole point of a Standard is that no single entity - eg Adobe or Microsoft et al - can futz with it by adding 'features' to make it more their own format based on their own particular marketing plans.
@NotFuzzyWarm: On first reading, I struggled to reconcile that I very much agree with this, but you very much agree with NAT, but NAT very much disagrees with me.
