In the case that any implementation attempts but ultimately fails to follow a specification that is a failure of the process. Perhaps the BIP was unclear or not sufficiently rigorous, perhaps the implementers made a well intentioned error. Regardless one of the reasons we have a BIP process is to avoid failures like these. The implementer should understand what they are implementing and the rationale for implementation details from reading the BIP. When they look at an implementation of the BIP it should match what is laid out in the BIP. Any (re-)implementation should not have to decide whether it should follow the BIP or whether it should follow what is in the Bitcoin Core codebase.

Consensus rules (and to a similar extent policy rules though at least on the base layer consensus rules are more concerning than policy rules) are extremely tricky to change especially at short notice. For bugs that pose systemic risks (e.g. an inflation bug) an emergency fix would be pushed and distributed at short notice and clearly any discrepancy with a BIP would not be our greatest concern. I think generally running code trumps words but with systemic risks and emergency fixes I don't think this would always be the case.

On whether Bitcoin Core determines the consensus rules in the case of such a discrepancy between its codebase and the BIP, there is a strong case for that today at the time of writing. Many consider Bitcoin Core to be the reference implementation and it is certainly the dominant implementation on the network at the time of writing. However, this is not guaranteed for the rest of Bitcoin’s existence. If at some future time consensus changes were made in Bitcoin Core that were strongly opposed by the broader Bitcoin community there would most likely be efforts to build and run an alternative implementation. Hopefully this will never happen but clearly Bitcoin’s consensus rules shouldn’t be hitched entirely to the views of the Bitcoin Core maintainers and contributors at that time. For example the Bitcoin Core maintainers and contributors should not have the ability to change the block reward schedule or to claim funds for themselves from particular addresses without community consensus. It is clearly not reasonable to expect the community to have to accept this because Bitcoin Core is argued to be the ultimate arbiter on the Bitcoin consensus rules.

In the case that any implementation attempts but ultimately fails to follow a specification that is a failure of the process. Perhaps the BIP was unclear or not sufficiently rigorous, perhaps the implementers made a well intentioned error. Regardless one of the reasons we have a BIP process is to avoid failures like these. The implementer should understand what they are implementing and the rationale for implementation details from reading the BIP. When they look at another implementation of the BIP it should match what is laid out in the BIP. Any (re-)implementation should not have to decide whether it should follow the BIP or whether it should follow what is in the Bitcoin Core codebase (certainly in the case of consensus rules intended for all implementations).

Consensus rules (and to a similar extent policy rules though at least on the base layer consensus rules are more concerning than policy rules) are extremely tricky to change especially at short notice. For bugs that pose systemic risks (e.g. an inflation bug) an emergency fix would be pushed and distributed at short notice and clearly any discrepancy with a BIP would not be our greatest concern. I think generally running code trumps words but with systemic risks and emergency fixes I don't think this would always be the case.

On whether Bitcoin Core determines the consensus rules in the case of such a discrepancy between its codebase and the BIP, there is a strong case for that today at the time of writing. Many consider Bitcoin Core to be the reference implementation and it is certainly the dominant implementation on the network at the time of writing. However, this is not guaranteed for the rest of Bitcoin’s existence. If at some future time consensus changes were made in Bitcoin Core that were strongly opposed by the broader Bitcoin community there would most likely be efforts to build and run an alternative implementation. Hopefully this will never happen but clearly Bitcoin’s consensus rules shouldn’t be hitched entirely to the views of the Bitcoin Core maintainers and contributors at that time. For example the Bitcoin Core maintainers and contributors should not have the ability to change the block reward schedule or to claim funds for themselves from particular addresses without community consensus. It is clearly not reasonable to expect the community to have to accept this because Bitcoin Core is argued to be the ultimate arbiter on the Bitcoin consensus rules.