Hi @Volker_E, thanks for offering this proposal. I am more however slightly more in favour of using Accent50 as shown in examples on the original task T266028.
It makes sense to me that the in-progress loader following an action taken by the user should be in the same “active” colour. IMO, the Accent50 colour is not necessarily just indicating something is actionable, but a more accentuated indication of an action. I also prefer in on an aesthetic level over the darker shade of blue.

Reasoning, Accent30 indicates a selected, active state in an interaction and isn't emphasizing the actionable state of it like Accent50.

This makes sense, although equally I don't think anyone mistaking this for a button. I think either are acceptable, I am a bit more partial to the current style, but that could just be because I'm used to it.

I'm also in favour of start by using the default Accent50.
Once we moved away from grey, the indicators will become more prominent anyways so I think it is better to go with the more common accent color.

I am in favor of Accent50.

One thought about the use of the color on the progress bar is that in either slow-loading or low bandwidth environments, it's hard to tell if any progress is being made or if your toolbar just crashed. One proposal to fix this would be to have a gradient that shows that the progress bar is slowly making progress. Another idea would be to have a 4th progress bar that is catering towards this situation. Thoughts?

The quick fix I implemented (and being used on Patch Demo) is to show the pending texture:

More commonly an animated texture would be applied to the bar itself (the blue part), such as in earlier versions of OSX:

So something like:

In T278126#6941463, @iamjessklein wrote:

One thought about the use of the color on the progress bar is that in either slow-loading or low bandwidth environments, it's hard to tell if any progress is being made or if your toolbar just crashed. One proposal to fix this would be to have a gradient that shows that the progress bar is slowly making progress. Another idea would be to have a 4th progress bar that is catering towards this situation. Thoughts?

The slow bandwidth usecase is a relevant one to consider. I wonder if there is a way to indicate activity without making the progress bar much more distracting for everyone all the time.

For example, in terms of timing we can consider including a signal that does not show continuously but only after a few seconds. Another idea could be to show such signal if there has been no significant progress after a few seconds (this may be harder to implement).

Building off of @Pginer-WMF and @Esanders comments, It seems like we have a few things to consider:

1. toolbar
2. color (which this ticket is supposed to be about)
3. animation of the toolbar
4. helper text

All of the examples referenced T278126#6941488 are effective yet clunky/outdated so do we need to decouple the issue of color from the treatment of this possibly additional state or should we address all the issues at once?

@iamjessklein Let's keep this ticket to scope and capture/copy & resolve the issues connected to Progressbar in parent T266028: Add “Progress indicators” to DSG and keep T75972: Loading indicators / Progress indicators are inconsistent. in mind.
I'm a bit concerned about quick fixes like the pushPending as it adds another type to choose from without defining the scope and issues solved by those types clearly, leading to more confusion for the users.