I can reproduce this with the following:

--source include/have_debug_sync.inc

--source include/have_innodb.inc

--source include/have_debug.inc

set @save_debug = @@GLOBAL.innodb_evict_tables_on_commit_debug;

SET GLOBAL innodb_evict_tables_on_commit_debug=1;

create table t1 (a int, key(a), b int) engine=innodb;

create table t2 (a int key references t1(a), b int) engine=innodb;

insert t1 values (1, 1);

insert t2 values (1, 1);

set autocommit =0;

--connect purge, localhost, root

BACKUP STAGE start;

--connection default

begin;

update t1 set b = b + 1;

# Commenting this makes the test pass

update t2 set b = b + 1;

--connect bug, localhost, root

set debug_sync="open_tables_after_open_and_process_table signal open wait_for go";

send

update t1 set a = a + 1;

--connection purge

BACKUP STAGE block_commit;

BACKUP STAGE END;

--connection default

set debug_sync="now wait_for open";

commit;

set debug_sync="now signal go";

--connection bug

--error ER_ROW_IS_REFERENCED_2

reap;

--connection default

# Cleanup

set debug_sync= reset;

SET GLOBAL innodb_evict_tables_on_commit_debug=@save_debug;

drop table t2, t1;

mysqltest: At line 39: query 'reap' succeeded - should have failed with error ER_ROW_IS_REFERENCED_2 (1451)...

This bug is represented as an assertion failure in f3cc51e4 (MDEV-29181), as was found by the latest RQG

AS far as I understand the idea of innodb_evict_tables_on_commit_debug, it is used to imitate eviction in a cheap way.
Unfortunately, for eviction it can be even more dramatic: as only half of the tables is normally evicted, we can end up in a situation when
both referenced and refegencing tables have refcount=0, but only one of them can be evicted. A referenced table may just stay in upper half of the LRU cache,
either because it's just in upper half in comparison to a referencing one,.

So I see a few ways of fixing it.
1. Allow safe removal of a single referencing table, just set foreign_table = nullptr for every foreign_set element (which is shared with a referenced table in referenced_set). Unfortunately, this didn't work for free, as only referenced_table could be opened on demand before, so some careful fixing will be required. Also
it would require a careful testing.
2. Do not remove a table whenever it has some still used referenced tables. If no tables are used, evict them from cache altogether. This will change the caching logic related to tables with foreign keys. Though it never worked correctly before. The whole relation graph will have to be checked. LRU seems a very core component, so modifications to it are unlikely and nominally require good testing. However, the changes will be carefully localized, and everything will happen under single dict_sys lock, so it looks less error-prone for me.
3. Load the missing tables on table open. For example, whenever table is going to be modified. Combine with 1. This can have some added cost for delete-only operations, however normally foreign tables should be represented. Reopening can only happen after a combination of FLUSH (or other tc_purge call) and eviction, but iteration over referenced_set is inevitable.

Approach #3 wouldn't save us from a parallel FLUSH+evict. What could be done is a reference count could be increased once the tables are loaded, but then DROP-ing a referenced table under FOREIGN_KEYS_CHECK=off wouldn't work.

Approach#2 would required a significant change in eviction logic. Besides, TRUNCATE/DROP will do it without waiting for release.

So I went by approach #1.

There code base already was expecting this possible, but with some issues, see MDEV-30103 .

marko please review commit 4021d847e, branch bb-10.6-MDEV-29181

This look OK to me. Please wait for stress test results.

This was tested OK, according to a comment in MDEV-29181.