I've been playing around with the download queues that already exist, and you can actually almost do pipelined transfers as it is! What you have to do is manually select each file for downloading separately. That creates as many separate queues as there are files to download. Since you can limit the maximum number of queues that can be active, you can use the queues as download slots for one file at a time by making sure each queue only contains a single file.
What I am trying to say is that the current queue-concept is almost the same as pipelined downloads. It's just phrased in the user interface in a way that doesn't make its usefulness clear.
To make this simple to use and understand, you just need to change one behaviour: When multiple files are added as a queue (either through multi-selection, or through downloading a directory with many files), every file is added as a separate queue, each file in a queue of its own.
Then there are some phrasings in the user interface to change. The concept of multiple queues is redundant. Since each queue now always contains only a single file, you could now simply say that there is only one queue. What you earlier called queues you now call download slots or something to that effect. (Since calling something that always has a single item in it a queue is confusing). And you could simplify the code by ripping out all that multi-file queue handling, every "queue" will now always be simply a single enqueued file.
I think the old queue-concept is a left-over from when there only was a single queue? When that became multiple queues, it became confusing, since you now had queueing in two dimensions (number of different queues, and number of elements in each particular queue). Making this change will reduce it back down to a single dimension again, however in the "number of different queues" dimension, rather than the original "number of files in a queue" dimension.
Anyway, I imagine that it could be reasonably simple to implement (basically, you always add every file in a queue of its own). The rest is user-interface text clarification.
Now, if that gets done, there are a number of user-interface enhancements that could be done, mainly regarding queue maintenance.
It would be great if you could multi-select in the queue, and change the download ordering of multiple files at once.
A function that lets you "cut" some selected enqueued files, and "paste" them back in elsewhere in the queue would also be really helpful, since moving a file up/down one position at a time is burdensome for large queues (100:s or 1000:s of small files).
A "Place first"/"Place at end" button-pair would also be really helpful, in particular coupled with multiple selection.
The suspend/resume queue functions could be simplyfied by making the suspend function simply swap the file in the selected download slot with the top file in the queue. The file can then be given a different priority by moving it manually to where in the queue you want it.
An increase/decrease number of download slots button-pair would easily let you experiment to find the perfect number of download slots for current conditions (particularly good if you move around with a laptop, but even time of day changes conditions). When a download slot is removed, the file in that slot is pushed back to the top of the queue again.
Anyway, though the explanation is long and detailed, all that careful thinking-through perhaps that makes the implementation quick and simple, yes? ;-)