I've come to see a single core as being the single greatest threat to Bitcoin out of all of this. A better situation to me would be a bitcoin P2P network with several separately developed cores that adhere to a common set of rules. The upgrade path is then always put to a vote. Any one core could then propose a change simply by implementing it (with a rule that after x% of blocks back the change it becomes active).
Then if people like the change, more will move to that core. This in turn would cause the other core to adopt the change or lose their users, and that is how consensus is achieved. If a majority did not like the change, they would not move to that core, and the change would never be accepted.
At no point in this do any set of gatekeepers get to dictate terms. Since no core has a majority of users captured, change would always have to come through user acceptance and adoption, and developers would simply be proposers of options.
Yes, in the long run a network composed of many parallel implementations would be the most robust and anti-fragile.
It strikes me that contentious consensus decisions such as this could serve as impetus for these parallel implementations. If miners and node operators "vote" on various hard- and soft-fork decisions by choosing to run different forks of the main client, then a more diverse software ecosystem could emerge. This should also be a less contentious way of coming to consensus, everyone simply choosing the client that will implement the policy they favor once a supermajority of the network agrees.
This would probably also require something better than "version number" for clients to communicate the consensus rules they are willing to follow. If several consensus changes are being considered simultaneously, then some sort of more fine-grained indication would be needed.