This is explained in the commit message:

However for system versioned tables we currently store the 2038 year max
timestamp as the 'max timestamp' which is used to detect current values.
This patch stores the new 2106 max value as the max timestamp.
For now, this handled by treating old rows with the old 2038 timestamp
as it would be the new max 2106 timestamp.
At some point, before 2016, we have to fix mysql_upgrade to update all
system versioning timestamps to use the new 2106 max timestamp.

But it's not treated as max timestamp, that's the point. Sorry I should have added an example from the beginning, but here it goes now.

On the old server (I was using the current 11.3):

MariaDB [test]> create table t (a int) with system versioning;

Query OK, 0 rows affected (0.041 sec)

MariaDB [test]> insert into t values (1);

Query OK, 1 row affected (0.014 sec)

MariaDB [test]> select a, row_start, row_end from t;

+------+----------------------------+----------------------------+

| a    | row_start                  | row_end                    |

+------+----------------------------+----------------------------+

|    1 | 2023-12-18 15:44:17.724987 | 2038-01-19 05:14:07.999999 |

+------+----------------------------+----------------------------+

1 row in set (0.002 sec)

So, the record is current and it is seen by normal select.

Now, starting bb-11.3-timestamp on this datadir:

MariaDB [test]> select a, row_start, row_end from t;

Empty set (0.003 sec)

The record is still there, but it became historical and is only seen by select for system_time all:

MariaDB [test]> select a, row_start, row_end from t for system_time all;

+------+----------------------------+----------------------------+

| a    | row_start                  | row_end                    |

+------+----------------------------+----------------------------+

|    1 | 2023-12-18 15:44:17.724987 | 2038-01-19 05:14:07.999999 |

+------+----------------------------+----------------------------+

1 row in set (0.001 sec)

My timezone is EET (taken from the system), in case it's important.

It looks like the approach I envisioned will not work for upgrades.
I am now adding support for fixing row_end as part of mariadb-upgrade.
For mysqldump we will need an option to update row_end from 2038-01-19 03:14:07.999999 to
2106-02-07 06:28:15.999999 for system versioned tables. We can backport this option to earlier version, like 10.5 which should fix this issue.

Fixed in bb-10.4-timestamp