Thanks, but seems like my conclusion was too hasty.
A more thorough test shows that both webdav and mount will read the executable to extract the icon. This will happen with or without "Show thumbnails instead of icons".
Apparently Windows has some kind of (timed) icon cache that blurred my tests unless each action was performed with minimum 10 minutes delay.
Good question, it made me discover the above and investigate why Explorer behaves so badly when using rclone mount.
This is what Windows requests from rclone each time you hover, select or right-click on an executable like rclone.exe:
DEBUG : rclone-v1.60.0-windows-amd64/rclone.exe(0xc0005921c0): _readAt: size=4096, off=0
DEBUG : rclone-v1.60.0-windows-amd64/rclone.exe(0xc0005921c0): _readAt: size=16384, off=47643648
DEBUG : rclone-v1.60.0-windows-amd64/rclone.exe(0xc0005921c0): _readAt: size=1536, off=47668224
That is 4K from the start and 17K near the end of the file (probably the icon resource). This amount of data would typically be transferred quicker than the human reaction/detection time.
rclone however has a default --buffer-size of 16Mi, so it reads 16MB from the start of the file and another 16 MB from the end. That will roughly take the above mentioned 30 seconds to complete on my simulated 10 mbps connection. That is an effective transfer speed of 5,600 bit per second seen from Windows. This speed is comparable to some of the very first phone modems I used 30+ years ago, so I guess this would cripple any modern (Linux or Windows) program performing small random reads.
With this knowledge I tried setting --buffer-size=0 which effectively reduced the buffer to 32KB (on my machine). This made Explorer nicely responsive, even with thumbnails enabled. I was even able to do reasonable pleasant Explorer navigation on a simulated 1 mbps connection (starting with empty cache):
rclone mount --network-mode --cache-mode=full --buffer-size=0 --bwlimit=100K myOneDrive:testfolder/ Z:
I also tried a few other things (downloading rclone.exe and browsing a folder with photos). It was slow as expected, but I didn't see any negative consequences of the much lower --buffer-size. Performance also seem fine when using the mount with --buffer-size=0 on my full 600mbps bandwidth.
I guess this explains the much better performance seen with the default installation/usage of RaiDrive. RaiDrive probably doesn't try to read (as much) ahead as rclone does with default settings, and it also seems to enable a small read cache by default.
So these are the rclone settings that seems to match the RaiDrive default settings:
rclone mount --network-mode --cache-mode=full --buffer-size=0 ...
@wslrj Does these settings improve/solve your issue?
A closing remark for the technically interested: I also briefly tried the same trick with rclone serve webdav, and that wasn't a success. Seems like the whole file is being downloaded irrespective of --buffer-size, I didn't investigate why or any details. That will be a challenge for somebody else.
More info on --buffer-size here:
https://rclone.org/docs/#buffer-size-size
https://rclone.org/commands/rclone_mount/#vfs-file-buffering
https://rclone.org/commands/rclone_mount/#vfs-cache-mode-full