My apologies, I was half wrong. All of my talk about UNIQUE was my thinking this was uniqueness checking, sorry for the noise.

The comments about the check being wrong are still valid though. A concrete case that breaks:
```
test=> CREATE TABLE t(id INT NOT NULL PRIMARY KEY, y INT);
ROWS: 0
test=> ALTER TABLE t ADD FOREIGN KEY(y) REFERENCES t(id);
ROWS: 0
test=> INSERT INTO t VALUES (1,1), (2,2), (3,3);
ROWS: 3
test=> DELETE FROM t WHERE id=2;
ERROR: Cannot delete from table `test`.`t` with id = 2 due to foreign key constraint `__fk_1` on `test`.`t`
```

Why? Because there is an entry after the self-check row that is to be skipped.

The exchange is primed with (2), as you point out, and the first next(true) goes to (2,2) -- the first real row. Then next(true) goes to (3,3) and then hasChildren() returns false. Then, in the calling code, entryExists() is called and the exchange still contains (3,3).

The entryExistsSkipSelf() needs to be more careful, something like:
- int origDepth = key.getDepth()
- hasChildren()
- next(true)
- next(false)
- key.setDepth(origDepth)