Hi William,

I personally prefer this solution, since it nails the problem
completely with one simple and obvious change. The BIP 62 approach is
more like a game of wac-a-mole.

The two are complementary, not competing. BIP62 prevents non-signers from mutating the transactions, which is very important. The 'Build your own nHashType' proposal enables chained transactions even in the face of signers mutating the transaction. I believe that integrating both will lead to the best defense against transaction malleability, and will enable more complicated uses of chained transactions (such as micropayment channels).

Best,
Stephen