What you are seeing is the scheduler using statically known knowledge, which results in an overly conservative build order, as I mentioned in my previous reply.
Key to understanding the process is that the build scheduler groups together devices into level sets statically at the start of the build process.
In the image you posted above, in that small subset of devices, the curve device will build first; the first expander and inverter will build together; the second expander will build by itself; then the combiner will build.
In reality, of course, the inverter will build almost immediately, which means the second expander has everything it needs to start building, but it does not. So you see each expander slowly building by itself.
This is not a bug, but an engineering trade-off – static build order makes the builder much simpler to create (no cross-thread communication is needed), and overwhelmingly the slow devices in WM will be erosion, blur, thermal erosion – all things that are multithreaded. Instead of idling, the extra cores usually will go to finishing off the current device, which is superior in the presence of multithreaded devices. Only with single-threaded devices does this deficiency become notable. Since most of the time the static builder doesn’t appreciably increase build times, there has been no need to sink significant effort into improving it.
In fact although it would be nice to improve the builder to dynamic ordering, in terms of engineering time it would be much faster to multi-thread the remaining slow devices and get better performance to boot, then design, test, and debug a new build system.
One possible interim work-around is to insert “spacer” devices in the network to line things up the way you want them; for example a clamp or a checkpoint device inserted to balance the flow will make both expanders build at the same time. I don’t generally recommend doing this (it’s rarely worth it), but if your network is being scheduled in a very frustrating way it might be worth it.
It is very little work to multithread the expander device; I’ll see if I can bump that up the priority list for you.