PostgreSQL v13 WAL sequence number question - postgresql

Question

I don't understand what are the 40,41,42,43 wal sequence files in my pg_wal directory?
According to the PostgreSQL documentation, segment files are given ever-increasing numbers as names, starting at 000000010000000000000001.
Why do the 4x segment files not appear in my backup? Why is there a 3F after 43?
# ls -clt /var/lib/pgsql/13/data/pg_wal/
total 81924
-rw-------. 1 postgres postgres 16777216 jan 29 10.45 00000001000000000000003F
-rw-------. 1 postgres postgres 16777216 jan 29 10.18 000000010000000000000043
drwx------. 2 postgres postgres 59 jan 29 10.18 <font color="#3465A4"><b>archive_status</b></font>
-rw-------. 1 postgres postgres 16777216 jan 29 09.18 000000010000000000000042
-rw-------. 1 postgres postgres 16777216 jan 29 08.18 000000010000000000000041
-rw-------. 1 postgres postgres 16777216 jan 29 07.43 000000010000000000000040
-rw-------. 1 postgres postgres 340 jan 27 19.13 000000010000000000000020.00000060.backup
My backup server wasn't available between 0:13 and 7:29.
My backup directory:
# ls -clt /home/pgbackup/wal/
total 524292
-rw------- 1 pgbackup pgbackup 16777216 jan 29 10:13 00000001000000000000003E
-rw------- 1 pgbackup pgbackup 16777216 jan 29 09:13 00000001000000000000003D
-rw------- 1 pgbackup pgbackup 16777216 jan 29 08:13 00000001000000000000003C
-rw------- 1 pgbackup pgbackup 16777216 jan 29 07:29 00000001000000000000003B
-rw------- 1 pgbackup pgbackup 16777216 jan 29 07:29 00000001000000000000003A
-rw------- 1 pgbackup pgbackup 16777216 jan 29 07:29 000000010000000000000039
-rw------- 1 pgbackup pgbackup 16777216 jan 29 00:13 000000010000000000000038
-rw------- 1 pgbackup pgbackup 16777216 jan 28 23:13 000000010000000000000037
-rw------- 1 pgbackup pgbackup 16777216 jan 28 22:13 000000010000000000000036
-rw------- 1 pgbackup pgbackup 16777216 jan 28 21:14 000000010000000000000035
-rw------- 1 pgbackup pgbackup 16777216 jan 28 20:13 000000010000000000000034
-rw------- 1 pgbackup pgbackup 16777216 jan 28 19:13 000000010000000000000033
-rw------- 1 pgbackup pgbackup 16777216 jan 28 18:13 000000010000000000000032
-rw------- 1 pgbackup pgbackup 16777216 jan 28 17:13 000000010000000000000031
-rw------- 1 pgbackup pgbackup 16777216 jan 28 16:13 000000010000000000000030
-rw------- 1 pgbackup pgbackup 16777216 jan 28 15:13 00000001000000000000002F
-rw------- 1 pgbackup pgbackup 16777216 jan 28 14:30 00000001000000000000002E
-rw------- 1 pgbackup pgbackup 16777216 jan 28 14:30 00000001000000000000002D
-rw------- 1 pgbackup pgbackup 16777216 jan 28 14:30 00000001000000000000002C
-rw------- 1 pgbackup pgbackup 16777216 jan 28 14:30 00000001000000000000002B
-rw------- 1 pgbackup pgbackup 16777216 jan 28 10:13 00000001000000000000002A
-rw------- 1 pgbackup pgbackup 16777216 jan 28 09:13 000000010000000000000029
-rw------- 1 pgbackup pgbackup 16777216 jan 28 08:13 000000010000000000000028
-rw------- 1 pgbackup pgbackup 16777216 jan 28 07:13 000000010000000000000027
-rw------- 1 pgbackup pgbackup 16777216 jan 28 06:46 000000010000000000000026
-rw------- 1 pgbackup pgbackup 16777216 jan 28 06:46 000000010000000000000025
-rw------- 1 pgbackup pgbackup 16777216 jan 28 06:46 000000010000000000000024
-rw------- 1 pgbackup pgbackup 16777216 jan 27 22:13 000000010000000000000023
-rw------- 1 pgbackup pgbackup 16777216 jan 27 21:13 000000010000000000000022
-rw------- 1 pgbackup pgbackup 16777216 jan 27 20:13 000000010000000000000021
-rw------- 1 pgbackup pgbackup 340 jan 27 19:13 000000010000000000000020.00000060.backup

Answer 1

The life cycle of WAL segments is:
They are created ahead of time, so that there are always some in stock to cope with activity spikes. This process is driven by database activity and min_wal_size.
At some point, the WAL segment becomes active and is written to.
When the segment is full or something else happens that causes a WAL switch, the next segment becomes active. If archiving is configured, the old WAL segment is archived.
Once the segment is archived and no longer needed for anything else (wal_keep_size, replication slot), it is removed at the next checkpoint. This can happen in two ways:
the old segment is deleted
the old segment is renamed and enters the cycle again at step 1
This is determined by max_wal_size, min_wal_size and database activity.
In your case, 00000001000000000000003F is the currently active WAL segment (it has the latest modification timestamp and a low number). 000000010000000000000040 to 000000010000000000000043 are the reserve for the future. 000000010000000000000021 to 00000001000000000000003E have been completed, archived and removed.
Never look at the timestamp to determine the order of WAL segments, it is all in the name.
This is documented:
The system physically divides this sequence into WAL segment files, which are normally 16MB apiece (although the segment size can be altered during initdb). The segment files are given numeric names that reflect their position in the abstract WAL sequence. When not using WAL archiving, the system normally creates just a few segment files and then “recycles” them by renaming no-longer-needed segment files to higher segment numbers. It's assumed that segment files whose contents precede the last checkpoint are no longer of interest and can be recycled.
The parameters are also documented. Beyond a certain degree of detail, resort to the (well documented open) source and its README files.