Interesting. Are users voting for BIP109 or Classic? It seems to me that they are specifically voting for BIP109 blocksize increase and as far as I can tell, there is no intent on their part to block uncontroversial upgrades that are independent of the blocksize topic.

CSV is totally uncontroversial and supported by everyone. The Classic devs said they would be adding CSV eventually but as you know they dont really have any active developers so it might not be until they have to. Bitcoin XT was the same with CLTV, I think they added it two weeks after CLTV activation...

But it seems philosophically that your vote is intent based rather than specific code until things get towards possible activation, because several of the other options dont really exist as such eg BIP 100 was never implemented and was retracted by it's author.  I believe Gavin retracted BIP 101 and that code is probably stale & XT unmaintained since Mike left.  In that spirit 0x30000001 seems reasonable to me.  If classic had a miraculous rebound up to 50% and growing, then some decisions would have to be made by you, classic developers and core developers and it would be a different scenario.  As it stands it seems that classic is not going to activate, and the vote mechanism being single rather than multi vote is creating risk of a political controversy that doesnt exist in user communities, and may inflame a problem that they did not seek: (ie the mechanism is interpreting as a veto/protest vote to stall technical progress, rather than a constructive for a 2MB HF increase).

There is the other issue, that once CSV becomes activated, anyone mining with a bitcoin node that does not validate CSV will risk producing orphan blocks after activation. In that case, if Classic do not add the patch in a timely manner, your pool would have to use Bitcoin Core and manually change the version number to show support for BIP109 or risk orphan blocks.

So the issue is Classic is vastly under staffed. They certainly do support CSV, and Gavin and Jeff etc have always spoken highly of CSV, I pretty sure even Gavin has said on a few occasions that CSV and SegWit are great, and should happen. His only complaint about segwit was "not fast enough".

In any case, I am not sure you can make nuanced user assumptions based on a system that was only really designed to get sentiment on the Classic blocksize increase. I think you can very easily say people are not trying to block CSV, it's widely anticipated by the ecosystem and there are dozens of companies waiting for it for their various applications including 21co, Blockchain.info, Strawpay, Lightning, Greenaddress etc etc.

It's unclear if CSV will activate or not with the current adoption, we're certainly at the cusp with ~94/95% but with variance it may delay or activate. I think we should be making a solid attempt to move the ecosystem forward and not getting stuck in political assumptions and I think you also may want to consider if you want to risk that the Slush voting mechanism becomes an trigger for a controversy that did not exist in users intent. For the longer term, personally I would worry about things like splitting votes for "dont cares". Since there are always such a large %age of dont cares, it would always result in a blocking result because 95% is so high a threshold. It may not really be a problem because overall Slush hash rate is about 3-4% of the network, but if the pool gets much larger, the voting could actually work against progress on the network.

For now I think we just want to progress Bitcoin on uncontroversial technical level, and not risk creating controversy that doesnt exist at user/miner level, if that makes sense.