Ironically the only current solution I can see is... putting regular pools in front of the distributed pool which of course adds centralisation detracting from the distributed nature, so it's hard to see how this is actually better than just using a full regular pool. I've yet to come up with a better solution to the problem, but that doesn't mean I've given up on looking for solutions entirely.
If I saw correctly you seem to have an idea already about merging the two ideas... if you find a way to introduce a method of communication between running ckpools, you are in effect creating a p2pool out of ckpools. Or am I misreading what was in your other main discussion thread?
Honestly if that is the answer to solving the share diff issue, then there might certainly be room to work with in merging the best principles and interfaces of p2pool to run on top of a well built pool foundation that you've created with ckpool.
The main reason I like p2pool is that I have enough hashrate where running a local node is really beneficial. I'd very much consider running a local ckpool instance, but it's not enough hash to find anything on my own since it's an isolated pool. By connecting into the p2pool network I get the combined hashrate which finds blocks at a decent clip.
There are some thoughts on this approach - putting a "traditional" style pool on top of p2pool's framework. I'm pretty sure the folks at mmpool are attempting this currently. However, as ckolivas correctly points out, just because you're using a decentralized back end, you're still centralizing mining power because miners have to register themselves on *your* pool. If I mine on pool A, then move to pool B, I'd have to re-register and effectively start again from scratch as a new miner on pool B.
Now, if the entire thing was distributed (i.e. register on one pool, and mine on any of them) that would be a different story, since every pool would have knowledge of every miner, just like current p2pool.