Ok, second attempt. Looking more closing it does seem that this is a problem with the interaction of the mergeIterator and the SSTableScanner. Basically the mergeIterator always needs to know what his "the next row" (during the reducing phase). If that next row was the one that the reducer ended up returning, we were fine (so with 1 sstable or if all sstables had the same rows, it was ok), but otherwise it might end up using the QueryFilter before it should for our get_paged_slice "hack".
Anyway, all that the mergeIterator needs during its reduction phase is to know the next key. So attaching a patch that delay the use of the filter until the row data is actually queried.