Interesting.  This can be combined with the system I suggested.

A node broadcasts 3 pieces of information

M_bits_lsb (1 bit):  Used to indicate M during a transition
N (7 bits):  This is the count of the last range held (or partially held)

M = 1 << M_bits

M should be set to the lowest power of 2 greater than double the block chain height

That gives M = 1 million at the moment.  During changing M, some nodes will be using the higher M and others will use the lower M.

The M_bits_lsb field allows those to be distinguished.

As the block height approaches 512k, nodes can begin to upgrade.  For a period around block 512k, some nodes could use M = 1 million and others could use M = 2 million.

Assuming M is around 3 times higher than the block height, then the odds of a start being less than the block height is around 35%.  If they runs by 25% each step, then that is approx a double for each hit.

Size(n) = ((4 + (n & 0x3)) << (n >> 2)) * 2.5MB

This gives an exponential increase, but groups of 4 are linearly interpolated.

Size(1) = 12.5MB

Size(2) = 15 MB

Size(3) = 17.5MB

Size(4) = 20MB

Size(6) = 30MB

Size(7) = 35MB

Start(n) = Hash(seed + n) mod M

A node should store as much of its last start as possible.  Assuming start 0, 5, and 8 were "hits" but the node had a max size of 60MB.  It can store 0 and 5 and have 25MB left.  That isn't enough to store all of run 8, but it should store 25MB of the blocks in run 8 anyway.

Size(255) = pow(2, 31) * 17.5MB = 35,840 TB

Decreasing N only causes previously accepted runs to be invalidated. 

When a node approaches a transition point for N, it would select a block height within 25,000 of the transition point.  Once it reaches that block, it will begin downloading the new runs that it needs.  When updating, it can set N to zero.  This spreads out the upgrade (over around a year), with only a small number of nodes upgrading at any time. 

New nodes should use the higher M, if near a transition point (say within 100,000).