Paying a meaningful fee to miners has no effect on the thousands and thousands of bitcoin users who have to store the transactions on their disk...

Sadly, chain pruning is by no means easy.  Pruning the index of transactions (blkindex.dat) isnt hard, and is likely to be done in the next release or the release thereafter.  However, pruning blk0001.dat really can't be done without making pretty significant changes to the way bitcoin downloads blocks.

Sadly, the most realistic way of doing it involves shipping chain snapshots as a part of the client download.  This introduces more trust in the decentralized network, which really isnt a good thing.  Hence why people are not eager to start working on chain pruning: many users will reject it.  Note that it also makes it very, very difficult for people to run old nodes (they wont sync properly), which in light of recent node statistic generation by luke, is looking like a very, very poor idea for network security.  In any case, chain pruning isnt coming soon as doing it really isnt pretty and could result in some pretty bad things for the network as a whole.

All your sad posts are making me sad now.

I suppose then, the best thing to do is find out how the free market copes with an exponentially increasing blockchain size.  It had to happen eventually anyway...

I suspect we'll see many more users move to a light client in the coming months.  I already removed the full satoshi client from all of my computers except one, simply because it really does take a toll on the machine it is on.

"So if you dont spend your coins in 96 hours you lose them?"

I knew my statement leading up to that was an issue as soon as I walked away from my computer...

Oh, come on, it's not forcing anybody!  It only encourages them. 

I have to admit I havent spent a huge amount of time thinking about it, but its definitely an interesting concept.  It does carry with it some of the issues of alienating old nodes which may have issues finding peers which have a full chain to give them, but I believe that is inherent in any chain-pruning method anyone has come up with so far.  It does complicate bitcoin as a whole very greatly, forcing everyone to follow multiple chains (or...I cant think of a way to switch over to a new chain cleanly without hard-forking) and heavily complicating verifying the initial checking (probably ending up moving the initial download verification to the same trust-model as SPV nodes, which is ok, but not ideal).  These complications only further the effort alt-client devs have to put in, which is already pretty huge and alt-clients are pretty important for the health of the network.  In the end, I dont really see anyone jumping to implement it, so I dont see it happening any time soon, but if it does happen, it will provide some interesting new features.

The same result can easily be achieved without forcing users to add at least 2 transactions per bet.

[For reference:  the idea I proposed is a special blockchain pruning method that allows nodes to verifiably query any address balance with only a couple kB download -- and the pruned data would be maintained & enforced on a second/alternate blockchain using merged mining]

Theoretically, the alt-chain created for this purpose is strictly optional.  No one is "forced" to do anything -- they only use it if they want to participate in creating/exchanging/verifying/downloading address-balance information.  One major benefit of the idea is how perfectly non-disruptive it is.

I agree that it would be complex.  But there's a lot of alt-chains already in existence that use merged mining, which probably provides 90% of the template that would be needed.  I don't mean to imply that there's anything easy or quick about it... just that a lot of work has already been done.

Otherwise, there's two options that both have serious downsides (compared to using an alt-chain).  But maybe some brainstorming can resolve it:
(1) Overlay network like what stratum is trying to do.  Issue:  requires some trust of other nodes, and malicious nodes can really muck up the network.
(2) Modify the main blockchain, forcing block-headers to include a valid balance-tree hash to be accepted.  Issue:  requires a hard fork. 

However, there's a dozen other things that could go in as long as we're doing a hard-fork, anyway.  If there's any inclination to believe it will have to be done at some point, earlier is better...