> I understand what you are saying there.. but it seems to me that if the coin has a network difficulty of finding a block at 1-2 and you are processing 500-1000 blocks at a time, by the time you send your work back to the server, the block may have already been found half way through your work and new one was released half way through your work.

It doesn't work like that.  Each hash a miner tries either meets some difficulty or it doesn't.  Each has has the same probability as any other hash of meeting that difficulty, so the average block rate the miner will expect to produce will be based on his own hash rate and the difficulty target he is trying to hit.  But there is no such thing as being 50% of the way to producing a block that meets any particular difficulty.  It's just like buying a million or a billion or a trillion lottery tickets a second.  Each one stands alone.

> Which means that you were hashing 250-500 extra blocks for nothing?  It may be just my lack of understanding how this works...

There will always be some stale shares based on the miner finding hashes after the network has accepted a new block.  But if the pool and miner are operating properly, there should never be stale shares based on not keeping up with the clock and the transactions, because the pool should accept oldish work for a bit of time after sending out new transactions and/or time.

But the difficulty the miner is targeting should not affect what percentage of his shares are stale over the long-term.

> I guess what i'm not clear on is the frequency of valid blocks generation by the network.  Are they 'generated' after previous valid block was found (x seconds after) or they are generated on set schedule every x seconds, regardless if blocks are found or not?

A valid block for the block chain is found whenever it is found.  The definition of a valid share is somewhat up to the pool, but should in general be any share generated by a miner that (a) would have been a valid block if it met the network difficulty at the time it was reported to the pool; and (b) did in fact meet the difficulty that the pool required of that miner at that time.

Again, the pools _already_ can set per-miner difficulties, and they do this to cope with bandwidth problems, but there is a spin-up time when the pool might be changing the difficulty for a miner, and might reject shares because they weren't difficult enough, even though the miner had been previously told they _were_ difficult enough.  This proposal lets the miner who knows he has a high hash rate start off at a higher difficulty.