MEMORY BTREE index: DELETE by key prefix skips a row after a previous lookup (regression from MDEV-40186)

After a lookup on a MEMORY table with a multi-part BTREE key whose later part is a string, a DELETE that scans by the key prefix leaves one matching row behind. ROW_COUNT() reports one row fewer than matched.

CREATE TABLE t1 (a INT NOT NULL, b VARCHAR(10) NOT NULL, PRIMARY KEY (a, b) USING BTREE) ENGINE=MEMORY;

INSERT INTO t1 VALUES (2,'v'),(1,'in'),(1,'out');

SELECT * FROM t1 WHERE a = 2 AND b = 'v';

DELETE FROM t1 WHERE a = 1;

SELECT ROW_COUNT();

SELECT * FROM t1;

DROP TABLE t1;

Expected: ROW_COUNT() is 2 and only (2,'v') remains.
Actual on 10.11.19, 11.4.13, 11.8.9, 12.3.3 and 13.0.2: ROW_COUNT() is 1 and (1,'out') remains.

10.11.18 and 10.6.28 return the expected result (official Docker images).

It does not reproduce when:

• the preceding SELECT is removed,
• b is INT instead of VARCHAR or CHAR,
• the index is a single VARCHAR column,
• the index is USING HASH.

The affected versions are the fix versions of MDEV-40186 (restart the index scan from the last found key), so this looks like a regression from that change: the restart appears to use a key left over from the earlier lookup.

Found through Cacti's poller, which deletes from its MEMORY poller_output table by local_data_id after a join, so completed samples stay queued and are processed again on the next cycle.