I have a clarification for the “NumBuffers-1 is the index of the oldest image” - part.
The scenarios illustrated in your initial post are for a case of continues acquisition with auto lock mode, right?
The green buffers are pending and cannot be reached by RBBuffSeq() in general. Only on buffers with which G2Wait() has been called on already can be accessed with RBBuffSeq(). Otherwise the access is undefined.
For your scenario 1, this is the case.
For scenario 2 the index “NumBuffers-1” would try to return the buffer index labeled “4” if you have at least called G2Wait() NumBuffer times. But, there is also no valid image at this location since G2Wait() has not been called yet for this buffer, it would have to be blue to work properly.
For most use cases, there is no real application for “NumBuffers-1”. But consider this:
RAM recording scenario: where the lock mode is on and you fill the whole buffer once to then do processing on it offline.
Since index “0” is the most recent image (as stated in the manual), and you want to go through the locked ring buffer in order of acquisition, you have to iterate RBBuffSeq() from “NumBuffers -1” to “0”.
In a case of “10” buffers and locked mode = on, you would iterate from “9” to “0” after 10 images have been acquired (as in G2Wait has been called 10 times). While “9” being the oldest image, “8” the one that has been acquired right after the oldest, “7” being the next image in line and so on.
That makes “1” the image right before the most recent call of G2Wait() while RBBufferSeq called with “0” represents the same image of the most recent G2Wait() call itself.
All above mentioned only applies, if the buffer is full.
(Mods, if this leads to more confusion, please just delete. 
)