Would like to propose for Cybersyn to allow specifying item-level priority, similar to item-level request threshold.

Use case will be for multi-item providers/requesters balancing (to override the default round-robin/proximity-based pressure relief). Practical example will be to balance the ore providers for core miners in Space Exploration, where I want to override the proximity-based pressure relief to keep the core miners running. In which station having more amounts of a particular ore will have higher item-level priority specific to that ore.

When an item has an item-level priority specified, station with higher priority items will be provided/requested first, followed by station priority if they have the same item-level priority, followed by the fallback proximity-based / round-robin distribution.

I can offer a second tier of priority only given to items with request thresholds set by optional station controls, essentially making optional station control have a reaction to receiving the priority signal as input. Any more specific than that and I am not sure how to allow the player to specify their per-item priorities. You would essentially need a third station control combinator which I don't particularly want to do.

yes, my impression was that another combinator will be required for the implementation.

Choosing between priority and request threshold wouldn't be ideal. If there is no other pragmatic way of implementing it then I would say don't bother - It is just an icing on the cake.

you misunderstand, I mean that if you have optional station controls, if it receives a priority signal, then all items which are having their threshold overridden by optional station controls also will have their priority overridden

And the item-level priority will be the same value as the item-level request threshold? I guess it can work - for providers yes since request threshold means nothing to them, not sure about requesters that require request thresholds.

Let's look at a case of trying to override the front-pressure relief mechanism of two requesters - numbers scaled down for simplicity:
1. Station A and B has to set their request threshold to 10 to prevent mini deliveries, and assume 10 to be the full train load.
2. Station A has to have priority for product X, station B has to have priority for product Y.
3. Station A: {X: 11, Y: 10}, Station B: {X: 10, Y: 11}

Will there will be problem if Station A cannot buffer more than 10 (because its request has to be at least 11 for it to trigger a delivery)? I am guessing no because after a train is dispatched to fulfill 10 items, it should not send a second train right? Another thing is that the buffer is usually sufficient for more than one train load, so this shouldn't be a problem. Lastly, the usual request threshold will be so much larger than the numbers required for item-level priority to work.

Can't think of a way it can go wrong for now, I guess it can work. However, it will become unintuitive to other users.

Station A: primary input: {r-threshold: 10}, optional input: {X: 10, priority:1}, Station B: primary input: {r-threshold: 10}, optional input: {Y: 10, priority:1}.
The above set of inputs is what would accomplish your desired function in the system I am proposing.
Notice how the "priority" virtual signal is overriding the priority of just the product it's paired with in optional input. So when the priority signal is received by primary input, it essentially sets the default station priority, whereas when it is received by the optional input it sets item specific priority.

Alternatively:
Station A: primary input: {r-threshold: 10}, optional input: {Y: 10, priority:-1}, Station B: primary input: {r-threshold: 10}, optional input: {X: 10, priority:-1}.

Your proposed implementation works if A and B have the same r-threshold to prevent mini-deliveries, but if that's not the case it becomes not feasible. The information of item-level priority has to tag along with r-threshold to make it truly item-specific. Nonetheless, I would say without new signal input slots, it complicates the current Cybersyn implementation for a partial solution?

On another note, I am thinking of the possibility of Cybersyn combinators to become more modular in the future, so that adding new feature like this will become easier. I understand the jank involved with handling multiple entities. But my rationale is that - not every input or output is being used for the different modes, e.g. one can probably go for the simplest implementation (with only a primary control input) if their station has no need for advanced feature, and save a bit of computation?

And currently I believe there is no failsafe or warning for when user messes up their setup (sorry if I am wrong on this)? E.g. placing two primary controls at a station (I think it messes up the global tables real bad?), or no warning when using optional control without a primary / at a depot, and all the janks one can think of.

Sorry for throwing out so much suggestion, I am sure you have something in mind. Just wondering what's your view regarding my proposal.

I do not plan to make the combinators modular, because in my opinion the user-facing complexity that introduces is not worth the niche types of inputs or outputs people might want. Friendliness to new users is a design priority, and new users won't know which combinator modes are actually useful. I already don't like exposing new players to wagon control and optional station control so early, but those at least are modes users will need to learn and use at some point.

I will add functionality to existing combinator modes where there was previously none, like giving optional station control a reaction to the priority virtual signal. I think you still misunderstand my idea. You get access to two priorities for a station, every item using the default station threshold gets the first priority, every item using a custom threshold gets the second priority. There is no reason each custom threshold has to be equal to the default threshold.

If two combinators exist it will go with the first placed, the global tables had to be designed around this principle. If there is a bug in this implementation I'd love to see it and fix it.