No, it will be fine.

After push this.mScissorStackOffset points to the values that were just pushed on stack so when we are doing another push (nested ClipEntities) we are getting previously pushed rectangle.

On popping things are a little bit different. When doing pop we do not want to revert to a value that was recently pushed to stack, but one step deeper. This is why there is predecrementation in glPopScissor.

Currently code is pushing/popping like this: 123 321
While it should be doing this: 123 21X (where X means co scissors)

Just have a look at "detailed call stack" below. It will be a little bit more apparent.

This is how it works:
- glPushScissor - rectangle A pushed; mScissorStackOffset is 4 after this method; no intersection done, A is saved at 4
- glPushScissor - rectangle B pushed; mScissorStackOffset is 8 after this method; proper intersection taken, B' is saved at 8
- glPushScissor - rectangle C pushed; mScissorStackOffset is 12 after this method; proper intersection taken, C' is saved at 12

- glPopScissor - rectangle B' is restored (it is read from 8); mScissorStackOffset is 8 after this method
- glPopScissor - rectangle A is restored (it is read from 4); mScissorStackOffset is 4 after this method
- glPopScissor - no scissor is used (it is read from 0); mScissorStackOffset is 0 after this method; this IS nasty since nothing was pushed at this position. It works fine though, because glDisable will disable scissors anyway. I think we might want to change behaviour here, but I have no idea what should be considered as a default/empty value for scissors (0, 0, 0, 0)? (-inf,-inf, inf, inf)?  A random value will do


NOTE1: rectangle C is never restored on pop. This is expected and proper behaviour. Current implementation restores to C on pop which is wrong.
NOTE2: yes, last glPopScissor is a little funky, but as I said- it works and I could not think of any good defaults to read from an empty stack.