Limitations which the row end as a part of PK imposes due to CURRENT_TIMESTAMP behavior and otherwise

Note: Possibly it's the matter of documentation, but before we proceed with documenting it, it needs to be confirmed as intended behavior.

CURRENT_TIMESTAMP freezes its value upon the beginning of the statement/function/trigger execution. Given that the row end column is added automatically to the PK, it means that certain DML statements that work with non-versioned tables will become impossible with versioning. Here is basic example for a single statement, it can of course become more elaborate and less degenerate within triggers or functions.

MariaDB [test]> create table t1 (pk int primary key, i int) with system versioning;

Query OK, 0 rows affected (0.15 sec)

MariaDB [test]> replace into t1 values (1,10),(1,100),(1,1000);

ERROR 1062 (23000): Duplicate entry '1-2038-01-19 05:14:07.999999' for key 'PRIMARY'

That is, everything that removes a row which is represented by the non-"row end" part of PK more than once within a statement/function/trigger will fail.

Although, maybe in the case above the reason is actually different, not related to CURRENT_TIMESTAMP behavior as such, since it claims that it can't insert 2038-01-19 05:14:07.999999, which is just wrong. But even if it goes as expected, it will still attempt to insert (1,<current timestamp>) twice and fail.