Appears to be from https://stackoverflow.com/questions/78019973/should-handler-open-place-a-table-metadata-read-lock-on-mariadb-myisam-table, where the user is upgrading from mariadb 5.5 and encountering an issue with old ported from ISAM code blocking a newer application that uses standard DML.

LOCK TABLES WRITE "Exclusive write lock. No other connections can read or write to this table", which means it can't continue while a HANDLER tbl OPEN because that would mean there is an exclusive write lock that isn't exclusive because the HANDLER tbl OPEN can read it.

So I'm thinking the current behaviour is correct, because if allowed in 5.5, the lock tables write wasn't exclusive.

I'm not convinced with this argument and don't agree this issue should be closed.

The manual page (https://mariadb.com/kb/en/handler-commands/) states ;-

...
Limitations
As this is a direct interface to the storage engine, some limitations may apply for what you can do and what happens if the table changes. Here follows some of the common limitations:

Finding 'Old Rows'
HANDLER READ is not transaction safe, consistent or atomic. It's ok for the storage engine to returns rows that existed when you started the scan but that were later deleted. This can happen as the storage engine may cache rows as part of the scan from a previous read.
You may also find rows committed since the scan originally started.
...

In the old version (5.5) of MariaDB this was possible and intentional - i.e. other connections must be able to alter content in the table whilst there is a HANDLER OPEN connection on it.
I would expect the LOCK TABLES WRITE command to block HANDLER READ statements. Instead the HANDLER OPEN statement is blocking every other connection from modifying rows in the table.

Surely this means that either the manual is incorrect, and the HANDLER READ statements have now been made transaction safe and consistent, or this is a bug and the HANDLER OPEN should not be placing the table metadata lock.