I'm aware of that project, but that's not the code I'm concerned about (sending coins). The reference implementation would be for validating transactions and the blockchain.
As I see it, the validation of tx is non-trivial (because of the Script functionality which we really don't use, for example). What happens if two implementations have a subtle difference? We'll have a split blockchain. In theory we would have to read satoshi's paper to decide who's on the right, but in practice the "official" implementation will prevail. At the moment, the oficial client is the law. And the law is written in C++, which concerns me.
We trust the core dev team to do the right thing. But I don't want to have to trust them.
C++ is a tool for speed, the functional languages are tools for correctness. We have no need for efficiency in the reference implementation, but of clarity, which will bring trust, which is what money is about. Trust in crypto in the case of Bitcoin.
Also if it depended on me I would freeze the specification now that we still can for only the types of transaction that people actually use. Fuck IP transactions, we don't need all that cruft. Keep it simple. Confidence in Bitcoin would be devastated in case of a technical failure. No more sripts besides the standard one. The only used they've had to date is to attempt buffer overflows. Fuck that. Satoshi made the script language non-turing complete for that reason, but even if it is a cool feature I think he should have skipped it altogether.
This way I can write simple code and know that it won't fail.
I can't write my own implementation of Bitcoin because I *KNOW* it is so complex, it will differ somehow from the official one.
I don't know if I'm getting my point accross.