Looks as if some cases of InnoDB index inconsistencies – see e.g.
MDEV-22373 – are missed by CHECK TABLE.
InnoDB currently ignores any other CHECK TABLE attributes than QUICK (which will suppress the time-consuming checks of the upper levels of the index trees).
Most importantly, InnoDB is ignoring the attribute EXTENDED, and is essentially only performing a MVCC COUNT(*) in each index. A verified case exists where the record counts in the indexes would match, yet the records do not match between the indexes. A true EXTENDED check should report any mismatch between the clustered index (primary key) and the secondary index records.
Note: By the design of InnoDB MVCC (see MDEV-17598 for some discussion), secondary indexes may contain multiple copies of a record, while in the clustered index the multiple versions are formed via a singly-linked list that the undo log pages are part of.
An extremely extended test would have to check that in any possible read view, the secondary indexes match the clustered index, instead of only checking the current read view.
It may turn out that only a special ‘locking’ variant of CHECK TABLE would be able to detect truly any type of mismatch.