Thanks for further clarification. I haven't needed such capability in a text editor, but probably I should look into what that provides.
And I don't see how such features are necessary to rule GVim as GUI. I have a fairly basic classification: TUI runs in a terminal, GUI have their own windows.
GVim is a GUI in the same way that a terminal app is technically a GUI. It is surrounded by GUI chrome and has menus and such, but you are working with unstyled plaintext as you would in any other terminal window.
Put this another way, you can tell the difference between something like vim and Emacs versus Kate and Microsoft Word. It is not necessary to get into the minutia of what makes all these text editors different to understand that they are fundamentally different kinds of applications. The former two are clearly terminal apps with GUI chrome around them, the latter two are clearly GUI apps.
Think what you're asking for is a vim interface built around arbitrary mouse usage and discovery, the latter being of utmost emphasis I presume. And yeah, it's a valid complaint that vim GUI implementers seem incapable of getting to that level and just put chrome around what is essentially a TUI instance.
Lack of mouse-led discovery likely also contributes to vim veterans being surprised that vim has this or that feature. TUI-orientation is quite tenuous when it comes to discovery of behavior. The whichkey family of plugins[0][1] is an interesting experiment in combatting this, but does nothing for the large case of commands that aren't mapped to a key by default, like the example of the 'earlier' command mentioned higher in this thread.
And I don't see how such features are necessary to rule GVim as GUI. I have a fairly basic classification: TUI runs in a terminal, GUI have their own windows.