Here's a patch with a fix for this issue, and with a test case.
The patch moves all the multi-probe logic out of TableScanResultSet and into MultiProbeTableScanResultSet, and instead created methods that MPTSRS could override where different logic was needed. In short:
1) Initialization of the start/stop keys has been factored out of TSRS.openCore()/TSRS.reopenCore() into a helper method initStartAndStopKey().
2) MPTSRS overrides initStartAndStopKey() and updates the keys with the actual probe value. This ensures that the keys now have the correct values when TSRS.reopenCore() calls skipScan().
3) Methods in TSRS that take a probeValue argument have been removed, since MPTSRS.initStartAndStopKey() now does all the work with retrieving the probe value and updating the keys.
4) Since the next probe value is fetched earlier now MPTSRS.reopenScanController() can no longer use the return value from getNextProbeValue() to decide whether or not it should be a no-op (it should be a no-op the next probe value was null, which means that the probe list has been exhausted). To ensure that we don't open scans in those cases, set a flag in initStartAndStopKey() to indicate whether or not the probe list was exhausted, and override skipScan() to check that flag and return true if no new probe value was found.
(As a side note to 4, this should only happen when the last element in the probe list is equal to the previous element. I cannot see that this special case is tested by InListMultiProbeTest. Looking at Ole's weekly test coverage report, it looks like the code that handles duplicate values in the probe list is not exercised at all by our current tests. I will add some test cases to exercise those code paths, but in a separate patch/issue since it's not directly related to this bug.)
I've started a full run of the regression test suites.