It is understandable that certain threads may start functioning before some others do - and these can lose order when showing up on display. This has no bearing on the way the file is assembled as it works just fine even when the display order is messed up.

Multiple threads can be created to concurrently download different sections of the same file and then on completion can be rejoined.

The current behaviour for showing progress on completed threads involves the disappearance of the progress bar. This can be substituted by a designated completion message for that specific thread.

There is no indicator of download rate currently.

As the thread counts go on increasing, the integrity of the file cannot be verified. The reason behind why this is happening is unknown for now.

This would enable users to know which threads are executing and completed first.

fetch only works now when there is a certainty in the file location but fails to make transfers happen when the resource URI involves multiple redirects.

The current display is contiguous enough that the segments till completion cannot be distinguished clearly.

There is no indicator for the estimated time left till completion.

Some resources do not provide a "Content-Length" header and fetch disallows downloading them. There should be a way to download those resources too.