Now, I'm aware that nothing prevents anyone from attempting an alternative implementation and that someone could conceivably read the source code and proceed from there.
Alternative implementations do exist though. Like
BTCD.
Shouldn't the reference implementation be one of many?
There should be only one
reference implementation but other alternative options for people to run as full node.
..
BTCD is not a unique node that allows people an alternative pat to make Bips or upgrades from.
read their comment on the link you provided
It properly downloads, validates, and serves the block chain using the exact rules (including consensus bugs) for block acceptance as Bitcoin Core.
..
It includes a full block validation testing framework which contains all of the 'official' block acceptance tests (and some additional ones) that is run on every pull request to help ensure it properly follows consensus. Also, it passes all of the JSON test data in the Bitcoin Core code.
basically saying it does everything it can to follow core
rather then know what the rules are and have its own less cludgy, buggy methods of doing things that get same result
its a sheep 'follower' node, not on an equal playing field alternative as cores control of roadmap decisions of upgrades
lets imagine if
core libbitcoin and btcd all wanted to offer gateways where people can make proposals for protocol changes. rather than all rely on core.
this can be done. and done communicatively.
simply by this:
if there is a new proposal. all 3 brands release a V23.x(a) where (a) is the proposal coded out and launched publicly on all three brands. thus all three brands can have their users all have access to it. and if (a) becomes a majority used protocol, then it activates and v.24 of all 3 brands become what the previous (a) was. where all 3 brands are then basing the protocol on the activated (a) proposal
..
this would be instead of current situation where people have to hope core devs 'ack' their proposal into core. core then may decide to merge and commit it into a core RC (at their own pace, decision planning timetable), core then release it, the community then have to use core to vote it in and if it then gets voted in to majority consensus, then then other brands then ad it to their code as sheep followers.
or where core decide they prefer their own plan and then just ad a mandatory thing into it where they simply ignore blocks/nodes passing old data(blocks not showing the upgrade flag) thus fudge a 100% vote in of their version as being 100%..