binlog-storage-engine and binlog-gtid-index combination

The description of MDEV-34705 says:

The GTID indexes can be stored inside the same tablespace as the binlog data
(eg. at the end of the tablespace), avoiding the need for a separate index
file. GTID index design is still mostly TBD, but I think it can be
implemented so that indexes are updated transactionally as part of the
InnoDB commit and no separate crash recovery of GTID indexes is needed.

With GTID indexes being guaranteed available, we can use them to obtain the
GTID state at the start of each binlog file, and avoid the need for the
Gtid_list_log_event at the start of the binlog.

It's unclear whether the indexing was implemented for the new binlog. I don't see any changes in either Binlog_gtid_index_hit or Binlog_gtid_index_miss when the new binlog is used. I also haven't found any tests referring to binlog_gtid_index in the binlog_in_engine MTR suite.

However, the variable binlog_gtid_index is still set to ON by default, which is confusing.

If binlog_gtid_index is meaningless in the context of the new binlog, I'd expect that a) it was set to OFF by default when binlog-storage-engine is enabled, and b) if it's set to ON explicitly in the config file or the command line, it would be either rejected, like log-bin=<name> etc., or at least would cause a warning.

If, however, it was implemented, then it should at least have tests for it, where its effect on Binlog_gtid_index_hit and Binlog_gtid_index_miss is checked.

Finally, if it hasn't been implemented yet but is going to be in the future, it needs to be added to the list of limitations of the first edition.