I don’t recognise the issues you run into. I have my own annoyances with Nautilus (the need to install nautilus-admin to be able to navigate to admin:// paths and the need to hit either / or ctrl+l to edit the file path) but none as severe as yours.

If the underlying filesystem changes, say a copy operation, the file manager view does not update without a manual refresh by CTL+R. This leaves the view in a stale state, presenting false file information to the user, who might never know until they do something bad. This is a showstopper bug that’s been hanging around since forever.

I don’t know what you’re talking about, on my machine directories get updated as copy/move operations are completed.

Personally I find auto update behaviour very annoying to be honest, but I can’t turn it off. Stuff randomly jumping around always irks me, I wish file managers would just show a little button saying “the contents of this folder changed, click here to refresh” instead of changing the directory under my mouse as I double click.

Why, when moving a collection of files or a directory within the same filesystem, does it actually perform a copy and delete operation, taking cpu and time, when the inode location could just be updated like mv does?

This line of code sets the “do not copy+delete when move is natively supported” flag. Based on this code, that should only happen when files are moved between different file systems (or network drives, or whatever). Collections of files are calling the move-aware method in a loop. Sounds like you’re hitting a bug? Are you using some kind of virtual filesystem or something?

Thumbnails? Why do they take longer to generate for images and video than than the totality of the existence of the universe?

AFAIK thumbnails are generated through subprocesses inside a sandbox, stored in a central cache. I can’t say that I’ve run into this except when thumbnails are generated for huge video files, but if your system is under load I can imagine the overhead from forking processes causing slowdowns. Nautilus uses a pluggable standard for thumbnail generation engines, so if Dolphin were to use the same standard, you could configure the Dolphin thumbnailer for Gnome and get KDE’s performance. Dolphin doesn’t seem to support that type of thumbnailing, though (they have their own Qt based interface), so you may need to write a wrapper for the KDE source code if you want to try that.

KDE doesn’t seem to do any sandboxing for thumbnailers, perhaps that’s why it’s faster?

As for batch rename, I’ve never used it, so I can’t comment on it. I tried to do it in Dolphin once, but I didn’t understand what kind of formats and options the popup wanted from me so I resorted to using the command line.