valerii, I agree with the description. We should study how to block the unconditional DELETE. The read-only server may be always exempted from doing that. Let me redirect the question to serg (thanks in advance!).
Alternatively the DELETE could be deferred until the table has experienced the very first update operation on the restarted server. If the restarted server is demoted into slave, obviously no DELETE would be binlogged.

Just a "binary" question is asked.

What about this logic: if auto-DELETE on MEMORY tables won't be replicated, replication will go out of sync. It will not go out of sync only if these tables are not replicated (--replicate-ignore-tables or something). So, if MEMORY table is ignored, its cleanup should not be binlogged, otherwise it should be.

valerii, arguably the DELETE action is a kind of SUPER-user one. And it also makes sense to register in binlog any data change. So an isolated gtid domain for local updates deems the only way forward.

How to make it error-free?
If one just specifies those domains in ignore_domain_ids of any Change-Master, would not it be enough?

Also notice a separate gtid domain may need to be assigned for updates over the MEMORY tables.
After all, the read-only server may require its slave service configuration to not accept the MEMORY table replication events.
(Alternatively Sergei's mentioning of replicate-ignore-tables would do the same).
Consequently, ignore_domain_ids = memory_table_domain_id would be necessary on all read-only 'intermediate masters'.

--read-only cannot affect it. If the server is read-only, one shouldn't be able to create slave-only MEMORY tables in the first place. If CREATE TABLE was allowed, then DELETE should be too.

If those tables are slave-side only and should not be replicated, they should be ignored, and auto-DELETE should respect it.

new domain-id makes sense if these changes need to be replicated. If they don't — they need to be ignored, and then they don't need a domain-id

serg, valerii: it must be clear the current DELETE binlogging policy makes sense only for restarted masters. (A pure) Slave should not log DELETE on its own. After all were it to receive a replication event on a post-restart empty table it would just stop with a typical ER_KEY_NOT_FOUND or such. When Slave also serves a master role then the user would have to organize gtid domains in her replication chain. Sure this measure alone won't help if a memory table is replicated throughout the chain while a slave-master server in the middle gets restarted so ultimately the restarter should receive a partial memory-table backup at the handshake with master (I have not tried to find one, but we should have a separate ticket for that).

--read-only then indeed is irrelevant to the pure slave which is supposed to never execute updates over replicated data/domains or if it does, at least it *must* not binlog them with gtids of the replication domains.
So that's a requirement to the user.
As to the server the pure slave should have read-access to empty tables without logging DELETE events.
That must be a solution.

Practically then, instead of deciding whether a server is the pure slave, why won't we extend the read-access-causes-no-DELETE over any server and only binlog DELETE when a server is about to write something into binlog (attempting to update a memory table or reads from it to update other tables)?

Assigning Sergei to reply to this.

I'm not sure I understand. Of course, DELETE is written to binlog only when a server is supposed to write to binlog. If it should never write anything to binlog, it has binlogging disabled, and then it won't write DELETE either.

serg, I verified the description that claims a mere SELECT from a MEMORY table causes
DELETE event into binlog, e.g of the slave running with `--log-bin`. That's a legacy of a 2004 commit that coded open_table_entry_fini() uninterested in
whether the read or write access the table is going to provide.

My suggestion is to binlog DELETE before the very first write access, on both master and slave.

What use case will it solve? An empty MEMORY table that is only selected from but is never written to?

(After self-reviewing to improve on few points)

serg, first not just 'selected from' but merely touched, like with COM_FIELD_LIST.

I have only one case in my mind. A listener/learned/slave process is subscribed for changes in the table.
(So it does not care what SELECT would do)
Clearly the reported past-crash-restart DELETE logging on such process could at least wait until the first write operation has arrived at it. If that one would be from a local connection DELETE would be logged. In other words, DELETE gets binlogged only at doing local writes.
Otherwise (it's from replication) it should not.
The first replicated event is recommended (to the user application) to be DELETE which
Valerii pointed to

MEMORY table is not empty on the master that the data are originally from (*or DELETEs are logged there already and will be replicated*),

So if it does so this replication setup is safe, else (the first event after the restart is not the DELETE) slave would error out volunteerly at once with a message like "Replicated event to the restarted slave is not an expected DELETE" (nothing gets binlogged of course for the table).

valerii,serg, (sorry for couple of typos, corrected) while the docs are made to discourage Memory table replication, we could do more to enforce
that. E.g with automatic @@skip_replication = ON for the duration of a statement that creates Memory table create/modify events.
This measure would at least not punish those who did not really mean this kind's replication but are currently punished with a "mystique" gtid OOO error, for unreading the docs.

As there might exist users who would insist to replicate it, @@skip_replication could be converted into an enum with the default automatic or smth value with its meaning to automatically evaluate to OFF. The taking risk users would have to set it ON explicitly.

maxmether, MDEV-25607 has a master side flavor. It's fine to auto-delete from Memory table on the restarting master, but the deletion can't be a query that may trigger a trigger (so TRUNCATE is safe).

We've established that if the MEMORY table on the slave is cleared because the server was restarted — this table cannot be part of the replication set, must've been ignored by the replication. Otherwise the replication will break because table's content on the slave will differ from the master's.

But this slave might be a master for some other slave or at least can write its own binlog (for fail-over or backup). In this case it can put the auto-delete into the next existing GTID that would've used this table anyway. Like INSERT...SELECT in SBR or any row event that uses this table in RBR.

Meaning the auto-delete binlog write would happen not on the first MEMORY table access (like, SELECT) but on the first binlog-relevant table access. And it would not need a GTID