Auto-generated DELETE for MEMORY/HEAP table can break GTID-based replication

It's known (see MDEV-25607) even if not properly documented (see MDEV-29795) that After server restart, a DELETE query is written into the binary log for every HEAP table, at the moment when it is accessed in any way, to reflect the restart emptying them for replicas. It is written unconditionally, and if we restart a replica with, say, server_id = 2 in the domain_id = 0, this extra transaction (logged nowhere else) generates out of order GTID for the domain and then causes replication break in strict GTID mode. Moreover, replication can be broken any time later after restart, by simple SELECT from low-privileged user (like SELECT from information_schema.tables that touches any MEMORY table), even on slave with read_only = ON.

While it seems to be by design, this behaviour breaks simple single level replication setups with strict GTIDs. For the end user this looks like a bug hard to prevent and troubleshoot. We have to think about some other solution, maybe do NOT write these DELETEs to the binary log if read_only = ON (and the table is accessed by the user without SUPER privilege?), use some special separate domain_id, something else?