Dialog boxes that open in a minimized or hidden state (must be expanded to full screen with my WM shortcut keys to see them).
I do see that very occasionally. I've never figured out what causes it, which makes it hard to report. I've noticed that (at least the way it presents on my system) is that the windows aren't minimized, they're just about two pixels wide and ten or twenty pixels tall. So if you can find the tiny window you can drag it bigger in addition to using shortcuts (or in case shortcuts don't work). It's like there isn't a minimum size for some windows?
Text entry into most fields is unreliable, for instance entering repeating characters causes issues with the text completion. Same when deleting characters (I select and delete now by habit).
I've noticed the double letter problem for sure. What's weird is that I reported it a while back and it got fixed, but then it recurred. For me it seems to be related to some kind of diacritic selection pop up? Like if I type two "n"s in quick suggestion I get a sudden flash of Spanish n with a tilde over it as an autocomplete suggestion which steals focus from the text entry window and that breaks text entry. Ditto if I type two o's in quick succession, I get a bunch of diacritical suggestions. For some letters it breaks text entry without offering diacritic suggestions (maybe because there aren't any?) like typing two "g"s. It's like JRiver is calling out to (or tripping over) some kind of text entry library that interprets two of the same character in quick succession as a request for diacritics. But the focus stealing/key eating is definitely a pain point.
Copy-paste is unreliable from outside->inside MC and vice versa.
I've never noticed that one. I guess there are two (or maybe three?) different clipboards on Linux (see
https://wiki.archlinux.org/title/Clipboard), which might be part of the issue. I don't frequently use the select/middle-click clipboard, and I tested just now and that clipboard doesn't seem to work in JRiver at all. I pretty much only use the control-C, control-V clipboard when moving text into JRiver, and that one has always worked consistently for me.
Alternatively, if you're seeing bad behavior with the Ctrl-C/Ctrl-V clipboard, I'm using Gnome with no clipboard manager FWIW, if you want to try and narrow down what might be different about our environments that causes it.
The modern tag editor is very slow, especially with multiple files selected.
This I definitely see. Tag editing is slower on Linux than it was on Windows for sure.