Ahh... I was thinking I wasn't seeing it right

By the way, I've certainly mined in your pool. Currently my gear is on MRR and has been rented pretty much non-stop. When it's not rented its pointed to ck's solo pool. The only gear I've got on p2pool any more are 2 S3s that have been running the long-term test on OgNasty's pool.
He was trying to use ckpool for that at some stage.
No idea what he ended up doing.
(ckpool recently added ipv6 support so maybe that's related to his recent comment?)
I'm pretty sure that it's ckpool on top of the p2pool backbone. You connect as BTCADDRESS-PoP to the pool. Every miner submits shares that are tracked just like they would be in a typical ckpool installation; however, they are all being pointed to a single address that mines to p2pool. It's actually a pretty ingenious way to handle variance for the small miners on p2pool.
I believe there's also work being done to use the proxy to be able to balance miner hashrate. The idea being there to try to mitigate the effects of "swamping" a node if a large miner comes onto a node with a lot of smaller miners, they could be proxied to a different node where their hashrate is more appropriate.
The only downside to it is that you're stuck on his node(s). You can't move to another p2pool node because your miner doesn't individually submit share-chain shares. Currently he's got two nodes running this. One in EU and the other is on the east coast of the US.
Yes, if you're using PoP method, you're tied to either of those nodes. However you can still connect to them using standard P2Pool methods like any other miner and if you failover your normal shares still count.
The ideas behind the way they're doing it are interesting - sub-pools which in effect create a hub/spoke architecture. This could well be a viable workaround to the variance issues, as smaller miners can find a local sub-pool to join which under the covers helps make sure they're mining on a node that is appropriate to their mining power.