This actually works whether or not the output is consumed completely. Even if consumption slows, stops, or restarts after stopping, the input throughput rate will never exceed 75%, the belts just buffer extra items during a backup. So yes, this is completely pointless if you never use the entire 75%...

I came up with a very simple way to throttle yellow and red belts to 75% throughput: input_throttlers.gif It's very hard to see the difference, but some basic math proves that this works. For red it's obvious, since half of a blue belt is 22.5 items/s, which is also 75% of 30 items/s, and obviously ...

Not sure which bug report this is a duplicate of, since the linked thread has nothing to do with input priority, but I guess this bug report lives in Duplicates now. One final update: Turns out this isn't necessarily caused by the first toggle, but by any splitter with an input priority set. For exa...

Sorry, I may have overcomplicated my example to make the effect more obvious and to show that this delay can matter, since it can screw up later logistics. Here is the same issue, with just a plain old belt of iron plates: splitters_2.gif This also demonstrates that this delay only occurs on the fir...

What did you do? Created a full sushi belt of alternating copper and iron. and sent it through freshly placed splitters like this: splitters.gif Toggled the input priority of one of the splitters merging belts (Toggling the input again had no effect, it's only on the first toggle) What happened? Th...