I was trying to manually check the number of items in the oplog just after calling truncate on it and did this:

        Cursor cursor(txn, *this, /*forward=*/false);
        int i = 0;
        while (cursor.next())
            ++i;
        log() << "Manual recount: " << i;

But it counts (and walks) the items that I just truncated, not the ones that remain. If I change forward to true, it seems to work fine.
Mathias pointed out that we're now doing some sort of caching in WT on truncate - possibly that's not taking proper account of forward vs reverse cursors?

in "class WiredTigerRecordStore::Cursor" next() method, AFAICS, reverseCappedInitialSeekPoint.isNull() is true, so we skip the whole of the upper chunk of code, then in the next section:

       if (mustAdvance) {
            // Nothing after the next line can throw WCEs.
            // Note that an unpositioned (or eof) WT_CURSOR returns the first/last entry in the
            // table when you call next/prev.
            int advanceRet = WT_OP_CHECK(_forward ? c->next(c) : c->prev(c));
            PRINT(advanceRet);
            if (advanceRet == WT_NOTFOUND) {
                _eof = true;
                return {};
            }
            invariantWTOK(advanceRet);
        }

that added PRINT(advanceRet) gives zero, and the id it ends up picking up is the last truncated record, ie if I did truncate to xxxxx0005, it starts from xxxxx0004 and works backwards to xxxxx0003, etc.