You are right, I should read the code indeed. A protocol defined in the code rather than in a specification - pros: no maintenance effort, no ambiguity (in theory); cons: difficult to read and understand, difficult to make other implementations (including new versions of the same program). The blockchain fork happened because devs forgot that Berkeley DB was part of the protocol. Without reading the code I find this bit messy.
"no ambiguity" <- that's exactly what failed. In v0.7, db.h, there is the following line:
That means, create a CTxDB class, that extends the CDB class. That class is from an external library. What's CDB? What version? What does it do? All this stuff is ambiguous. Yet just "include every external" library doesn't work either; how far back do you go? While not as issue now, with really large blocks even subtle stuff like performance differences between different hardware implementations are can cause forks even with identical software.
Believe me, the developers understand the importance of the problem very well. As an example Pieter Wuille and others have been working to prevent OpenSSL differences from causing a fork with IsCanonicalSignature() and similar. I don't happen to agree with Gavin on everything, maybe even not on most things, but I can agree that he has been taking his roll in pushing testing and stability very seriously since he was hired by the Bitcoin Foundation, and for that matter, even further back than that.
There aren't easy solutions to specification problem, and I really think that writing yet another specification in addition to the imperfect one we already have is currently a waste of limited manpower. It might always be a waste of manpower - Bitcoin is in uncharted computer science territory with its extremely strict requirement for consensus.