On the other hand, if I select the same 30 files and add them to the background transfer queue simultaneously, only the transfers which are currently in progress appear in the queue, with all pending transfers only appearing once they become active transfers.
The queue total is also shown as only "1" in this situation. All of the simultaneously added transfers have been grouped together:
So doing effectively the same thing (adding multiple items to the background transfer queue), two slightly different ways, results in very different behavior!
1) Is there a design reason why all pending transfers are shown in one situation but not in the other? Or is this just an anomaly that has not been addressed yet?
2) As this behavior is quite surprising from a user's perspective (we assume there is a problem if added pending transfers are not visible), will you consider adding a note in the documentation, so people understand that this is by design and there is no problem? It feels like items are not successfully being added to the queue if we can't see them!
Currently, this unexpected behavior appears not to be mentioned in the documentation:
I find that, in the case of multiple large files, the inconvenience caused by pending transfers not being shown until they become active outweighs the convenience of being able to add multiple transfers simultaneously. Due to this behavior, I always add multiple large files separately, one at a time, rather than simultaneously, to ensure that all pending items are visible in the background transfer queue.
3) Will WinSCP eventually be updated to create consistent behavior here, so that pending transfers for multiple items added simultaneously will be visible in the queue, just as all pending transfers for items added individually are currently visible?