Thank you, spachev! I think that it is even simpler than that: the field should not be written at all. The history is:

• On every page, InnoDB reserved 8 bytes at FIL_PAGE_FILE_FLUSH_LSN and excluded it from page checksums.
• On shutdown, InnoDB used to update those 8 bytes in the first page of each file of the system tablespace, without using the doublewrite buffer or redo log. This risky write was removed (and this field lost all of its original meaning) in MDEV-27199.
• Later, those 8 bytes were repurposed for various things, such as the SPATIAL INDEX R-tree "split sequence number" and the MariaDB encryption key ID. At that time, the logic was revised so that only the first page of the system tablespace would be updated on shutdown.
• A conflict in the repurposing (inability to encrypt SPATIAL INDEX) motivated a file format change (innodb_checksum_algorithm=full_crc32, MDEV-12026).
• In .ibd files, the field never had any special meaning.

If I got it right, the time-consuming operations on the table db1.t1 in t2.test are necessary for advancing the LSN. I tried a different way of reproducing this, by extending an existing test that uses a special trick to advance the LSN:

diff --git a/mysql-test/suite/mariabackup/huge_lsn.test b/mysql-test/suite/mariabackup/huge_lsn.test

index 3349ef40df8..98aa73cec4f 100644

--- a/mysql-test/suite/mariabackup/huge_lsn.test

+++ b/mysql-test/suite/mariabackup/huge_lsn.test

@@ -56,6 +56,12 @@ exec $XTRABACKUP  --prepare --target-dir=$targetdir;

 --source include/restart_and_restore.inc

 --enable_result_log

 SELECT * FROM t;

+FLUSH TABLE t FOR EXPORT;

+copy_file $_datadir/test/t.ibd $_datadir/test/t_copy.ibd;

+UNLOCK TABLES;

+ALTER TABLE t DISCARD TABLESPACE;

+move_file $_datadir/test/t_copy.ibd $_datadir/test/t.ibd;

+ALTER TABLE t IMPORT TABLESPACE;

 DROP TABLE t;

 rmdir $targetdir;

 let $targetdir= $targetdir_old;

With or without the patch, the IMPORT TABLESPACE would crash:

mysqltest: At line 64: query 'ALTER TABLE t IMPORT TABLESPACE' failed: 2013: Lost connection to MySQL server during query

…

mysqld: /mariadb/10.3/storage/innobase/fil/fil0crypt.cc:2696: bool fil_space_verify_crypt_checksum(const byte*, const page_size_t&): Assertion `mach_read_from_4(page + 26U)' failed.

In the current 10.6, the same modification to the test would cause a different type of failure:

mysqltest: At line 66: query 'ALTER TABLE t IMPORT TABLESPACE' failed: ER_NOT_KEYFILE (1034): Index for table 't' is corrupt; try to repair it

I will try to fix that as well.

The problem with the above test is that DISCARD TABLESPACE forgets that the tablespace was default-encrypted. If I add explicit ENCRYPTED=YES to the CREATE TABLE statement, the file can be imported. Preserving the .cfg file did not help. This finally reproduced the problem as reported.

It turns out that as part of MDEV-21132 in 10.5.0 the function PageConverter::update_header() had already been rewritten to zero-initialize the field FIL_PAGE_FILE_FLUSH_LSN_OR_KEY_VERSION in the first page.