Potential Transaction Lock Bypass via Cache Layer in Vector Index Internal Table

While reviewing the code related to the vector index implementation, I came across an interesting behavior regarding transaction locks on the internal vector index table.

MariaDB introduces a cache layer (TABLE_SHARE::MHNSW_Share) for the vector index, which may bypass the storage engine for certain read operations. In particular, for locking reads (e.g., SELECT ... LOCK IN SHARE MODE, SELECT ... FOR UPDATE), which are normally expected to go through the storage engine (via handler) and acquire transaction locks, the cache may intercept these reads — potentially skipping the storage engine layer entirely.
This means that transaction lock behavior on the vector index internal table becomes uncertain or inconsistent. In the current implementation, this doesn't seem to break correctness since writes and locking reads are serialized. However, semantically, this changes the transactional locking guarantees on that table.

Questions:
Is this behavior known and intentional by design?
Is there any plan for this in future versions?

Not sure if this is the right place to report it, but I'd be happy to discuss this further if needed.