I'm not positive, but I think you just recreated the bitcoin blockchain itself...

The p2pool network is all one shared mining endeavor.  Anyone can set up a p2pool node (hence the p2p part of the name) and join the network; and your mining efforts on any p2pool node still count towards your reward, so long as you use the same payout address on all nodes.  The rewards are split among participating miners based on shares earned. In turn, the shares are tracked on a sharechain that's almost identical in concept to the bitcoin blockchain, except shares are issued much more quickly (once a minute, I think, rather than once every ten minutes on the blockchain).  It's possible that a dead or orphaned p2pool share is still a valid bitcoin block, and even if it doesn't get added to the sharechain, the miners get paid for it. Similarly, a valid and accepted share is frequently not a valid block on the bitcoin network.

The transactions being considered for inclusion in a block by the p2pool network are obtained from a standard bitcoin node, so tracking what transactions the pool is working on would be no different from getting a list of pending transactions from any bitcoin node's memory pool. In both cases, any given transaction is not guaranteed to be in the next block, or in any block for that matter.

I suppose you could create a fork of p2pool with its own independent sharechain; the software's all open source. If one of the major pools shifted their backend to this forked-p2pool, it would be mostly invisible to end users. For pools where the login is a bitcoin address, no change at all would be needed to the mining end, though some changes would be needed to the UI, of course. For pools where a different login is required, I would imagine they'd still have a bitcoin address on file for eventual payouts, and that could easily be reused to pay the miners when blocks are found.

Bear in mind, though, that funds from newly-found blocks are unspendable ("immature") until they have over 100 confirmations, versus the more standard six confirmations for a payment transaction that most pools currently do. That impacts usability for users.

I strongly suggest reading through the p2pool thread (or at least, the first post and the last few pages, as the thread is huge), then reforming your proposal a little more clearly and posting it there for feedback. While I use and support p2pool, I'm hardly an expert on it.