I think that the original intent (that got corrupted) was that comparator would hold the last search key component regardless of whether it was a lower bound (for GT/GTE/forward) or an upper bound (for LT/LTE/reverse), so we weren't calling it "end" and we weren't supposed to be adding startingBoundExpr's value to the search key until we KNEW what direction the scan was going -- we were just supposed to hold onto it in comparator until then, saving the trouble of popping it back out.

I understand that this is not what the code you found was doing but maybe that's a better approach than undoing the search key when we find we want a reverse scan?

I am having a small problem with all these variables named start... and end... because then when we decide to reverse scan we end up "starting at the end and ending at the start" which is confusing. I would rather name things lowerBound and upperBound so then we can say that we normally start at the lower bound and end at the upper bound. But if we reverse the scan, we start at the upper and end at the lower. Either way, start always mean where we start and end means where we end.