Doesn't works this way. "Voting" means that this mining system already supports given method, but it will be enabled only after specified date.
If you want to vote for one version, but in case of other one winning switch to the other, you need to implement BOTH with a some kind of switch. And this switch should never br triggered after the end of this voting. Adds complexity and poosibly error-prone.

Actually I don't think there will be any choice.

I can predict the future:
1) Slush and BTCguild support BIP16
2) Luke-jr supports BIP17
3) Some small pools support BIP16
4) I'll check if there is considerable support of BIP16 and if it is, then I'll implement it too.
5) BIP16 wins.

Well, or nothing happens.

My pledge is paid (50 BTC).

Post a fresh address here, so award can be sent and checked by people.

All those BIP16/BIP17 (types of pay-to-script) and BIP11 are doing the same thing, which can allow you to require confirming your TXes from your mobile phone or some other separate device.
(It's already possible technically, but no client currently exist with appropriate functions, and this TX would be "strange"(non-standard))

The point of voting is to a) select the most suitable implementation, b) deploy it safely.

Yes, I would be.

Also, you should note that I'll vote for /P2SH/ if considerable part of other miners will. It's not like I'm completely against it.
My position is rather "Vote for doing it in a better way unless impossible" and not triggering the avalanche by voting myself first.

Actual mining should be decided accordingly to the voting result.

Would be nice if you can add info about which blocks they belong and which one is orphaned.

Possibly won't work this way. With "old validation rules" 1) both BIP16 and BIP17 will be "non-standard", but mined by supporting pools (unless stopped by not relaying to to way to miner), 2) more importantly, if someone is mining by old rules, then under some circumstances he can create a TX, redeeming any BIP17 TX, that belongs to someone else, causing evil blockchain forking (depends on hashing power of both branches).

No, I'm not.
I think that it's some broken client or attack against some broken client.

You can try to monitor for transactions with multiple instances of same input, that's what happens too, as my monitoring nodes show.
I heard that there was some old client storing them in memorypool or doing something else.

UPD: Also it may be caused by people restoring their wallets from backups or using wallet.dat copy accidentally.
What we should especially care for is double-spend attempts in orphaned branches.

BIP17 is less "compatible" with old clients and under some circumstances can allow redeeming other people's TXes if the network suddenly stops supporting BIP17.

But both BIP16 and BIP17 are incompatible with old clients to the enough level so we can't say that one is "significantly more" compatible anyway.

As I understand, there was a possible way to make pool's blocks invalid/orphaned, which can be an attack against the pool if this pool's rules state paying miners for invalid blocks.

I think that the only dev against BIP16 is luke-jr, who is offering BIP17 instead.

Actually I can manually ask many bitcoin developers with good reputation about what vote should I give, but there are 2 problems:
1) They possibly will be all for /P2SH/
2) This won't solve my goal of having better solution

Asking my miners to vote would be "democratic", but sadly they don't know what's the difference, how this will affect Bitcoin and will mostly fall for current FUD on the forum.
Surprisingly I got just only one PM asking me what I'll be voting for, so looks like most forum members don't really care or they believe that time will settle things.
(No, this doesn't means that you should PM me now :)

Also, Gavin's signature says "Send Tycho a PM or email and ask him to support P2SH for a more secure Bitcoin" like I'm currently against "more secure Bitcoin".
But I'm not.

No. Luke-jr initiated a rumor that Gavin is hired by some company going to produce hardware/software solution for 2-factor authentication and this is the reason he is pushing so hard.

Disclaimer: I don't think that this is true.

No, the whole point is in having private keys on separate devices.

He is for BIP16.
And I don't know how he is going to mine enough voting blocks before 1 Feb.

Actually it can.
Just insert /P2SH/ tag in appropriate % of your blocks :)

Actually AFAIR, the "voting" ENDS 1 Feb.

I don't actually think that this proposal can break something, but rather expect some better solution for this problem.
Well, I also believed that Gavin's OP_EVAL patch is good too because he is Gavin, and Deepbit was the first pool to support and vote for OP_EVAL. Until it turned out to be exploitable, buggy and not the thing Gavin really wanted. Luckily no harm was done, but lesson learned.

1 Objection: there are clearly no consensus between devs or miners about the exact method of implementing pay-to-script thing. That's the reason I would prefer dividing it into two separate stages - 1) implement plain multisig and long-address multisig support, 2) decide about pay-to-script method and move 1 into it.
This would give us both time for deciding on stage 2 and allow 2-factor authentication and escrow-services support with a small downside of using pubkeys instead of pubkeyhashes and a bit longer output scripts.

2 Objection: (less important) this proposal makes strange use of scripts: it's like having a compiler that can only allow the source to contain just one line #include "source2.c", which contains the actual script. Somewhat hackish. I would prefer either normal scripts or no scripts at all in TX's output.
Also I don't like the script to be in serialized form, but this is not a real downside at all.

3 Objection: I don't want to become the single entity to decide on this. That's exactly the opposite of what Gavin says. With current 2% of /P2SH/ support Deepbit would be the force to push /P2SH/ into existence, not the other way around.