What I am assuming is that:
Initially the first record is read from each of the SORTINxx files.
INREC, when present, intervenes and effectively the input records from the files become new input records to the merge process.
The merge process decides which key is lowest and passes that for output, via OUTFIL, OUTREC processing, whatever, if present.
The merge process then requests the next record from the file which had the lowest key.
The file to which that corresponds is read, INREC gets the record and makes a new record to pass to the merge process.
The flip-flopping is only happening because as each new input is processed, INREC assigns the next highest sequence number. The INREC will have been processed with each initial record from the files, prior to the merge processing being entered.
Internally to DFSORT, I'm not saying that I know how the "requests the next record" or anything works (is it pushed or pulled, as it were) but my solution was on the above assumptions. If it doesn't work like that, my solution is a bad one.
I had looked at the EQUALS processing for the MERGE to see if that would "get in the way", but since the keys are unique/unique-when the-merge-is-operating (like the suggestion that it would still work with a single digit) I used NOEQUALS, but with EQUALS merge would respect the order of the record appearing on the files when keys are equal - so, if SORTIN01 and SORTIN03 have equal merge keys, EQUALS will ensure the SORTIN01 record appears on the output before the SORTIN03 (assuming multiple-more-than-two SORTINxx's) record, whereas NOEQUALS would take whichever was the most convenient at that time.