Thanks for sharing your thoughts, good pointers and very interesting discussion.
I was thinking for a while and get increasingly convinced as I think more that the concept NameCoin client software being hard dependency for any application utilizing NameCoin severely restricts the use.
Generally, it's easier to modify Bitcoin code than to write Namecoin code from scratch. Given that maaku and others have been working on UTXO code, I think it's a good idea to let them handle those details. The worst possible outcome would be if we adopted something on our own, Bitcoin adopted something better 3 months later, and we had to hardfork to be able to merge Bitcoin's version.
Yes, it makes lots of sense... I wish the BitCoin UTXO was progressing faster. After I've looked at maaku blog I realized that I've seen it some time ago. It seems like the progress is quite slow. I should say that BitCoin UTXO is substantially more complex and pursues slightly different goal than the ultimate NameCoin UTXO:
a. from bitcoin perspective no transaction is ever expired, i.e. all unspent transactions need to be part of UTXO tree. That's not the case with NameCoin.
b. NameCoin has much higher standard of verification robustness. BitCoin SPV client can afford to be fooled assuming the potential loss is acceptable or if there are other, out-of-band mechanisms to recover from failure. Example: BitCoin SPV accepts payment of X coins to sell a video card. It is ok for SPV+UTXO client to mistakenly accept a spent output, assuming full validation is done later, before the card is shipped. With NameCoin the mistake is almost always not recoverable. Example: there is nothing I can do to recover from using the wrong PGP key to send an E-mail to someone due to SPV+UTXO weakness exploited by malicious third party. My main point is that what BitCoin community may adopt for SPV+UTXO is not necessarily and, in fact, likely, not to be "THE SOLUTION" for NameCoin. Would you agree?
Lastly, I should say that I did not mean to put up a proposal for someone else to implement. The idea was rather to build the proposed solution if the community is willing to take it in, assuming satisfactory quality and robustness.