I was thinking about this the other day, actually, and I think I got a good solution to the problem.
p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.
Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.
That's similar to my idea, except mine was all current rounds of shares are based on a prior psuedo block, instead of the prior p2pool share. One huge advantage of the current layout is each node verifies all the prior shares. That's why each share has to contain the payout info for the p2pool miners, so when the "lucky one" that is a block is found, everyone is paid accordingly.
My idea would mean payouts are based on the last pseudo block, not last shares found. The work submitted is based upon a "pseudo" block based upon all the shares submitted between the last two BTC blocks. That "block" would be built in a defined order, ie:
root: last "true" BTC block
share #1: first share (based on timestamp) submitted
share #2: second share (based on timestamp) submitted
and so forth. If a collision on timestamp is found, them some other logic has to be used to determine the tie breaker.
That way each node can still verify all the prior shares and work is still decentralized.
It also means work is only restarted when a BTC block is found, roughly every 10 mins, instead of every 30 seconds.
There may be a flaw in my theory.
M