This series fixes irange::legacy_upper_bound behavior for VR_ANTI_RANGE (actually [4/5] does). It turns out the interesting behavior is relied on in multiple spots (maybe not so many but fixing things lead to fixing more things when trying to understand what happens).
So apart from fixing this possible wrong-code issue it removes the odd behavior of calling the functions with pair == 1 which is because VR_ANTI_RANGE get num_pairs () == 2 which is because of "reasons" (the other parts of the series show what I ran into). I have bootstrapped and tested patches 1-4 together on x86_64-unknown-linux-gnu and am now testing patch 5 ontop which looked like natural cleanup here. I didn't try to construct a wrong-code testcase, ranger probably never builds legacy ranges, so I'm not sure how easy it is to get an anti-range we end up querying upper_bound on. OK for trunk or stage1? Thanks, Richard.