unexpected replace behaviour when long unique index on system versioned table

Test case to repeat the failure:

CREATE TABLE t1 (data VARCHAR(7961));

INSERT INTO t1 VALUES ('f'), ('o'), ('o');

ALTER IGNORE TABLE t1 ADD UNIQUE INDEX (data);

ALTER IGNORE TABLE t1 ADD UNIQUE INDEX (data(1));

SELECT * FROM t1;

SHOW CREATE TABLE t1;

ALTER TABLE t1 ADD SYSTEM VERSIONING ;

SELECT * FROM t1;

REPLACE INTO t1 VALUES ('f'), ('o'), ('o');

mysqltest: At line 10: query 'REPLACE INTO t1 VALUES ('f'), ('o'), ('o')' failed: 1062: Duplicate entry 'o' for key 'data'

This problem happens when versioning + long unique hash index involved.
In write_record(), if the failed unique index is not last then we do
delete the record and insert again. Since it is a versioning table,
we do try to ha_update_row(). But it fails in check_duplicate_long_entries_update()
and returns HA_ERR_FOUND_DUPP_KEY. Irrespective of engine, behaviour is same.