It would play out as a more efficient version of what's happening between XT and Core today. Imagine that there are 5 competing implementations, each with between 10 - 30% of the node base. They all run essentially the same consensus library because everyone knows it's very important to follow the longest chain, although they differ in features. OK, so a few years down the road the community feels that a change needs to be made: we need bigger blocks! Multiple proposals are put forward (as they are today), a big debate ensues (as it does today), and then each software implementation picks their favourite proposal and implements it to activate some time in the future (like what Bitcoin-XT did with BIP101).
I believe this would be helpful to achieving consensus because now the user base has the ability to express their free choice more efficiently. They will tend to migrate towards one of the particular implementations. In an effort not to lose their user base, developers for the other implementations will make changes that at least make their code compatible (non-forkable) with what looks like the favoured solution.
It's a sort of 'spontaneous consensus' event. Of course, I can't prove that this will work, and that's one of the reasons why Bitcoin is an experiment. However, if we need centralized development to keep Bitcoin decentralized, then it seems to me we've already lost.
and to our Russian friend .There is good quote.If there is not possible to know what is about it is propably all about money