This would've been a lot better received if it was brought up while the technical discussions were still ongoing. I originally proposed something like OP_EVAL in https://bitcointalk.org/index.php?topic=46429, and I think P2SH achieves everything I wanted out of that. CODEHASHCHECK is arguably better, but only slightly - certainly not by enough to justify delaying deployment. Getting some sort of multisig transactions working is rather urgent, and P2SH is the implementation we have, and it carefully avoids opening any cans of worms.

What this really seems to be about is politics - LukeJr is uncomfortable with Gavin having the power to alter the Bitcoin protocol. I think that this power should be phased out eventually--but not yet. We'll mark that transition with a "1.0" version number. We still need protocol improvements. Gavin's shown no indication that he'd ever abuse his position, and he's the only one who's actually putting in the work required. And this is a really bad time to start a power struggle, because LukeJr isn't really going against Gavin - he's going against the output of a community discussion which he didn't take part in.

(As for the technical side - the issue seems to be that P2SH introduces a new interaction between the concept of "standard transactions" and the scripting system. Before, a transaction would be accepted if it was standard and the script returned success; now there's an additional requirement, which is that one of the standard transaction types now calls for you to rerun the script in a different way. This means that the "standard transactions" concept is now actually part of the scripting system, rather than a secondary sanity check, so it can't be fully dropped in the future. However, the special case is on the sender-script side, and I don't think allowing nonstandard scripts there was ever plausibly a good idea. I do still want to see the standard-transaction types broadened to include fancy tricks with time locking, but that's considerably less urgent.)