This is a complicated question. Currently, there's an incompatibility between p2pool and BIP91 in that p2pool will mine a transaction-free block on top of the longest chain seen if p2pool hears about a new block but bitcoind does not inform p2pool about this block. While I think this is the correct behavior during normal operation, it is clearly incorrect behavior during chainsplit conditions, so it will need to be disabled for the next month or so. I will be including that change in the new branch I'm working on that merges SegWit and large block generation capability.

I am not convinced that this is the correct action to take. P2pool generally does not validate the blocks that other nodes are trying to mine except to ensure that the payouts are fair. I'm not sure that we should start now. On one hand, it serves as an added incentive for people to ensure that they are BIP91 compatible. On the other hand, it disincentivizes miners using p2pool as a tool to vote their conscience. I tend to believe that the latter objective is generally more important, but I'm not sure in this particular case. It may be that people would want to exploit p2pool to mine minority-chain blocks while still getting paid on the majority chain, which could be a problem. Perhaps the best solution is just to fork the share chain again, and let anyone who wants to disobey BIP91 do so on their own minority sharechain. However, that approach would require the most work of any.

That would actually be a difficult rule, since p2pool does not store a copy of the blockchain anywhere, and is unable to evaluate whether 750 of the last 1000 blocks have it set.