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.
In my opinion, there is nothing wrong with creating an ISO standard for some format or protocol if you do not plan to implement any
major revisions for it, minor ones only. So on the contrary to what might be thought after my first reply, I don't see PDF's "staying put" as a bad thing, and as a file format its better that it stays like that.
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.
Bug-resilience is only achieved if the N independent implementations all review every pull request that is submitted, only allow direct commits from a small group of people, and are tested thoroughly at a protocol level to stamp out regressions and accidential forks.
Can Bitcoin Core afford to do this? Yes, because it's manned by dozens of developers. Whether alternative clients could afford to do so however is doubtful. If you have an alternative client maintained by just 5 people, they might struggle to completely test and review all changes, let alone implement new protocol additions.
The hard fact is, most people do not want to maintain 200,000 lines of reference client code alone, which is the only reason we have a single client anyway. Otherwise this space would be buzzing with reference clients. Many promising OSS projects have been started by a group of a few people but fizzled out a few years later simply because the devs are burned out.
To understand how much 20000 lines is, I give this comparison: I myself am managing a codebase about six times smaller than this at work, and even that is exhausting when done alone. I don't see how 5 or even 10 people can update a 200K-line codebase in a timely manner. So the question of having alternative implementations of a program at this scale has already been answered through the efforts of other developers: "No". (It's also the reason why, at 6 million lines of code, you don't see forks of the Linux kernel floating around.)
It effectively means that most clients would not styme progress by rejecting feature upgrades in Bitcoin Core, but they would quite literally not have enough manpower to implement them in the timespan of a few weeks. Thus the implementation takes several months or even years to develop, if at all. This unnecessarilly bogs down the schedule for rolling out the features to users at a protocol level, as there would be many users of the less-maintained client, but no work is being done to actively develop the required support for it although it could be desired by the alternative maintainers. In fact, it is very common for users to be using slow codebase, examples include every exchange whose wallet engine does not support native segwit addresses in 2022.
Or another example - Although some SPV wallets still don't support taproot, imagine if some of them were connecting to the protocol using an alternative blockchain, which itself has not yet implemented the taproot support code for lack of manpower. This would have had a downstream effect for those wallets which wanted to support Taproot addresses, but can't because it depends on support from the upstream reference client.