The earlier argument (^) about remote miners not working was a bit of a farce, as shown by the above numbers.
The thing to focus on in order to make sure things work is the timestamp rolling support in ASIC mining software. We need to ensure that it can roll ahead of the current time (and potentially backwards, though that would require an extension to getwork).
...
Sorry - I don't get the point of this comment.
Why do you need rolling the time?
Unless I've completely missed your point, you don't need to roll the time with Stratum or GBT, you roll a value in the coinbase instead, named (IMO badly) the secondary nonce instead of screwing with the block timestamp (which is a hack) unnecessary
P2Pool can't handle simply altering the coinbase script. P2Pool internally has a structure that describes how to recreate the coinbase transaction, including the coinbase script, but that can't be changed because the hash of that structure is stuck in the last txout. P2Pool uses it to create short, self-contained proofs of work by storing the SHA256 midstate with shares and computing the
generation transaction's hash using that midstate and the hash of that internal structure.
TL;DR: If the coinbase script is altered, the hash in the last txout of the generation transaction has to be changed too.
However, I discovered yesterday that Stratum is flexible enough to roll any data in the coinbase transaction at all, though, so rolling something in the last txout script is probably possible (though it would require a change to P2Pool's rules).