One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).
This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.
Imagine if Bitcoin Core/XT, btcd, libbitcoin, BitcoinJ, Toshi, etc. all got together to make sure there was a common test suite that was a strict superset of all the relevant unit tests in each codebase.
The next step would be for each implementation to make sure to add any missing consensus-related tests to their own repositories. Repeat the process as necessary.
After all that was done, you could use the test suites as the basis of a spec.
Organizing that is something useful that Bitcoin Foundation could have done, instead of... whatever it was they did.
If bctd is the best and most well documented code that mysterious group of highly funded spooky dudes who nobody knows can pump out then it would be interesting to fork it as the basis for a viable project on one of the many forks that the Bitcoin blockchain is going to blossom into. I'd use it (as long as I can compile it and compile the compilers that compile it.)
At this point I have little interest in a common spec and test cases and such. We're past the phase where multiple implementations are very valuable, and may be into the phase where the opposite is true and makes no logical sense anyway.