The sort a keyset walk actually runs under: the caller's orderBy followed by every primary-key column it does not already carry, each ascending.

This is the sort an adapter must ORDER BY, not the caller's orderBy. keysetPredicate expands the lexicographic comparison over this resolved sort, so a backend that orders by the caller's orderBy alone leaves rows sharing a sort value in an order the database picks freely — and the predicate then skips or repeats them. That is the same row-loss the key tiebreaker exists to prevent, arriving through the ORDER BY instead of the WHERE, and it is invisible to a fixture whose tie groups happen to be stored in key order.

Both the predicate and every adapter's sort read this one function, so the two cannot disagree about what "the next row" means.