A progress bar should not indicate progress over multiple tasks — a segmented progress bar is better, or a series of spinners, or just a single spinner for the whole set. A progress bar should measure exactly one metric, where the total is known.
With multiple things wrapped into one, you often end up in situations where 0-99% (or whatever) might happen super fast but that last 1% takes ages, making the progress bar useless as a "something's happening" indicator.
Those old windows installers used two bars: the top one was basically a steps indicator (file N of M, for example) -- just like the single bar for multiple tasks. But the second bar was a per-file bar. So if step 99 took longer, you had a second bar showing you that steps/files progress.
My demo has unfortunately fallen to web bit rot and needs to be updated, but the code is here to explore: https://github.com/worldmaker/compradprog
It didn't take me long to realize that the progress bar measured bytes written to disk, but when it was seemingly "stuck", it was creating a lot of small files.
Instead of bytes written, what I really cared about is "how done are you?" and that would have been better represented by a function of both number of files created _and_ bytes written. I don't think the weighting of those two had to be very accurate to be a big improvement.
If there are multiple independent tasks, give me multiple independent indicators of their state. Multiple instances of the same class of task can of course be grouped, you don't need to list every file copy independently, but a file copy and an external dependency installer shouldn't be two stops on the same progress bar.