So, I have experimented a lot with multithreaded copying between partitions on a Network drive. These are the only situations where I saw significant speed gains, but these are mainly due to Windows being able to offload the actual transfer to the Network drive itself, so data does not go to the Windows client and back, only status info does. Windows (and Robocopy) does this with some magic tricks. For this specific situation, move a file from one Network share to a different Network share, I have created a "Robomove" button with the following script:
@hidenosel:f
robocopy {sourcepath$|noterm} {destpath$|noterm} {allfile$} /MOV /MT /ETA
This copies, then deletes (i.e. moves) all selected files from source to destination with eight parallel threads (the Robocopy default).
The first line hides the button as long as no file (or a directory) are selected.
The second line runs Robocopy (on Win 10 and Win 11) with the correct parameters. Because of odd path parsing, the noterm modifier is absolutely needed if a path name contains a space.
I tested this for a couple of days now. Against standard copy this speeds up stuff on the same network drive (but different shares) by a factor of roughly four on my end. Your mileage WILL vary.
Other copy operations are not sped up measurably with the one exception of copying hundreds of small files to/from a networked drive, where the multithreading takes off some of the overhead, but again your mileage WILL vary massively and I'd rather use DOpus copies/moves with the "Unattended Operation" feature for these scenarios to get better logging and such.