If a provider is filled below the request threshold of a high priority station it will ignore this station in favour of a low priority station with a lower request threshold it can fullfill. This not how I would expect it. In practice that makes priority useless if you only have a slow trickle of an item and stations of varying request sizes.

So you can use a decider combinator to only allow the provided item signal through to the station when it is higher than your highest request threshold in the network. That is the intended solution to that problem.

That would mean I have to know the highest request threshold in the network, which means if I ever change that over to course of a game, I have to go back and change all other stations and probably more important it means I have to constantly communicate and organize that in a Multiplayer game between all players.
Additionally for mixed item providers that creates a lot of overhead as I would have to separate out each item the moment stack sizes on that station are not uniform. In general it sound like provide thresholds with extra steps and constraints instead of having it as a signal to begin with.

The expected behaviour, which I forgot to mention, would be the high priority station getting partial deliveries instead of none at all.

Personally I think outside of the train configuration stations should be agnostic in design in regards to other stations.

That's actually a great point about coordinating multiplayer games. I don't think I took that into consideration enough when designing this mod.

So I think the most intuitive behaviour that I am leaning towards is that if a request station has the highest priority but the provide station does not have enough items, the provide station is "locked" from providing to lower priority stations until it can fulfill the highest priority request.

I do want the request threshold to behave as an "absolute minimum" delivery size. So, after accounting for locked slots, no delivery is made that is less than the request threshold, which is why I am leaning away from the behaviour you describe.

So I think the most intuitive behaviour that I am leaning towards is that if a request station has the highest priority but the provide station does not have enough items, the provide station is "locked" from providing to lower priority stations until it can fulfill the highest priority request.

I think this makes sense. But to clarify the detail for this particular case (front-pressure), if stations with the same priority have different request thresholds, does it make sense to supply station with lowest request threshold first, or round-robin?

My thought would be round-robin, so you know it always cycles around to all stations sooner or later.

good point, I believe round-robin can be done fairly easily in the back end.

Locking deliveries to any lower priority station until the highest priority is satisfied sounds like expected behaviour and also would be agnostic. *

Same goes for round robin between stations of equal priority. A simple one with a delivery each would probably enough and less confusing than actually equally distributing resources.

edit: Btw If you want I am part of the Redmew admin team and run the modded games there. I could set up a run with the mod and see what problems come up in MP.

That would be wonderful, getting feedback on multiplayer. I have no testers for this mod it's just me in a a couple of single player worlds.

This suggestion is now implemented in version 1.2.0.