With GTID replication, relay logs cannot be relied upon while purging binary logs on master

I know from the corresponding thread on the mailing list that it is an intentional change for the sake of crash safety:

There's a well-known problem in MySQL that relay_log.info is not
always in sync with the database state, and killing and restarting
server at an unfortunate time will cause it to re-execute last
statement and potentially break replication. Did you fix this
situation with GTIDs and rpl_slave_state table? It looks like with

Yes. When using GTID, relay logs are ignored whenever slave threads are
restarted, such as slave server restart, events are fetched anew from the
server starting at the current GTID position.
⸺ knielsen, Re: GTID replication and relay_log.info

With traditional (binlog-position-based) replication it is quite possible and even reasonable to setup master binlog purging procedure based on the slave IO thread status: as soon as the IO thread is done with a master binary log and switched to the next one, all events are in the relay log, and the master binary log can be purged. It is efficient in the sense that if the slave thread is far behind, a lot of disk space can be spared by not storing the same events both in the master binlog and in the relay log; even more so if the server features the sql_delay (master_delay) functionality introduced in MySQL 5.6, and the slave is configured to keep a time gap with the master.
It also saves the network traffic if the lagging slave gets restarted, because the local relay logs are preserved and the IO thread does not have to re-read all the events again.

So, all in all, I expect there are real-life configurations which rely on this behavior.

Now, with GTID the relay logs are not stored on slave restart any longer, so users must not configure their purge procedure this way, but should use SQL thread position instead. It needs to be explicitly documented, because otherwise users can experience irreversible loss of events.