As for using tabs, well, as convenient as this may sound it would come with very significant changes that I do not have the time for to implement in code - not to mention the database implications. I'm sorry I don't have a more positive answer to that.
Having said that: I do appreciate the suggestion, as you can see in other posts I always try to implement requests if they are do-able. 😊 

As for the tabs, I was hoping just to have tabs regardless of whether it would fix the issue or not. it would just be nice to have multiple "jobs" open at once is all.

Thanks

As for working with SMB shares:

On both my Macs, using RMTV with SMB shares works flawless. So nothing needs to be changed here.

I have a M1 Max running Tahoe 26.0, connected over WiFi 5 (!), and my ancient Trashcan, a 2013 Intel Mac Pro running macOS Sequoia, over 1Gb Ethernet, and both machines have zero problems when using RMTV. Things run fast, even with ffProbe enabled.
Note: my SMB share is on a QNAP NAS (Linux based OS).

I'm using it right now as we speak over WiFi 5 (on my M1, a few rooms away from my WiFi router) to debug a bug that was reported by another user related to ffProbe. Not to mention that most RMTV macOS users do exactly the same, without issues, which suggests that you may have a network issue.

As far as network related issues:

There is absolutely nothing I can do to fix this in RMTV.
All network traffic is handled by macOS and your network, and files are just accessed by RMTV as if they were local files.
RMTV doesn't even know they are on a network share.

The fact that you see this with several builds of RMTV only confirms it to be an underlaying problem with your network.

Having said that; I feel your pain.
I have seen freezes like that before caused by what feels like congestion on the network in the past.
It's been a while (upgraded my network and fine-tuned things as far as I could - mind you: I'm not an expert).
I've experienced this especially with filemanagers like ForkLift and PathFinder that totally freeze when moving a lot of large files.

This freeze still happens every now and then as well, but only when my M1 is running on batteries and macOS thinks its a good idea to shutdown WiFi when the lit is closed - but once the WiFi is up again, and the mounted shares are active again, things run smooth again.
So anywho ... I do feel your frustration with this.
In the end it sounds like you have some kind of network congestion.

I'd recommend, if you haven't done this already, to test without WiFI.
Make sure to disable WiFi in macOS, since macOS occasionally decides to use WiFi instead of Ethernet for no obvious reason.

Ideally test this with the integrated Ethernet port if your MBK has one.
If not, and you're using a USB dongle for this, try a different port or a different dongle.
I ended up replacing mine with a 2.5 GbE USB dongle from AliExpress - so not the most expensive one 😉.

Note that WiFi 6 or 7 has no added value in this - as I can see by my WiFi 5 performing very well for this purpose.

As for the multi-tabbed/multimodal request;

For one, it wouldn't fix the freezing as it is not a CPU/process related issue.
macOS is the one handling all the network/SMB stuff and we'd just double up (or worse) on the load and traffic causing even more congestion.
In the end this would only make things worse and cause RMTV to freeze more often and quicker.

I'd be more than happy to help and see where we can get this to work better, but I'm afraid it's one or the other thing in your network causing this.

Setup:  Networking between iMacPro (intel) with 32GB RAM and 2GB net port and a M1 Max MacBook Pro with 64 GB RAM and wifi 6e/7. Both machines running SMB 3.

I just did a list of 26 files, which are already on the Plex Server, and the app has come to a crawl processing one file every 3-4 minutes.

This needs to be fixed. It has existed on almost every build I have used. The idea of moving all files to a local hard drive just to rename them consumes way too much time. Some tv shows are close to 100GB of data. Moving them locally, renaming them, and then moving them back to the server is just not feasible and adds complexity to an otherwise simple operation. Being able to do in-place edits is very much needed.

While most of the time it just slows everything by an order of magnitude, I have had several occasions where the app just crashes out.  A process that goes from instant for even large lists, to 4-5 minutes per file seems to be broken. I have not run into this in the newest build...but the incredible crawl is still there.

SIDE NOTE:  If this is something we are stuck with, please consider this:  Could you make the app multimodal so we can have windows per process?  ie: like photoshop allows for tabs and each tab is it's own work area, can we do this with RenameMyTV?  This way I can be running multiple jobs at once.  I can have something that is renaming stuff on the network running in one tab and taking however long it takes.  Meanwhile, I can actively be working on a different directory or a list of files, in another tab. Most likely local stuff or it would compound the slowness of the network one.

Either way, this idea of using tabs and having multiple jobs open at once would be very helpful and useful adding a lot of power to the user's toolbox.