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.