If we block scans, we block progress. We don’t want to prevent folder A from pulling a change because it needs to do a scan first and folder B is already scanning.
Except that the workaround to this problem - pause all the folders, then unpause one, wait for it to finish scanning, unpause the next one - ALSO blocks all progress. As well as being really timeconsuming and annoying. And not working around this problem, letting syncthing scan all the folders at once and build up a massive disk IO queue - ALSO blocks all progress AND stops anything else that uses the same physical drive from doing anything either.
I don’t see how the issue you raise means the fix should be rejected when it makes things better and it doesn’t make anything any worse.
If literally what it did internally was start all the folders paused and unpause them one at a time when they were ready that would be totally fine by me.
I’m seriously considering having to ditch Syncthing over this - at least in one use case. One of the things I’m using Syncthing for is to move backups from a production Sql Server to a backup server (and my development environments). When Syncthing decides to rescan all the folders simultaneously it flattens the backup drive (which is a separate device from data and logs!), and somehow that also means that Sql Server then grinds to a halt. If I’m lucky I can get onto the server to stop Syncthing, if I’m not I have to reboot it and then stop the syncthing service before the scan starts up. Having your backup solution break the server that it’s supposed to be backing up is a bit of a red flag.