TL;DR
Quality decider and arithmetic combinators can handle multiple simultaneous input/evaluation/outputs.What?
Decider and arithmetic combinators currently take one set of inputs, apply one set of equations, and provide one set of outputs (a "calculation"). For complex circuit logic, arrays of combinators can be unwieldy and space-consuming, particularly on platforms. Further, aside from the additional hit points, there is no real incentive to craft quality combinators.These issues could be addressed by allowing combinators to provide "active calculation slots": the ability to act on one or more defined calculations per combinator, with the number of active slots dependent upon the quality of the combinator: normal quality provides one active slot, uncommon provides additional active slot(s), etc. Each active slot effectively operates as an independent combinator of the "host" type (decider or arithmetic), and all calculations on a host type are performed in parallel by default.
Further, instead of only passing results to one or both output wire colours, the host interface would present an option to "chain" calculations internally for sequential processing. Chained calculations execute on the next tick, consistent with signal propagation via wire between physical combinators. In decider combinators, chained calculations could be addressed conditionally depending on the result of the prior calculation, using slots to facilitate if/then functionality within a single host. For arithmetic combinators, chained calculations would allow complex operations across multiple ticks within the same host entity.
Combinators may be given any number of calculations, sequenced in any order. Calculations which are not placed in an active slot remain dormant until manually resequenced into an active slot by the player, or, the combinator's active slot count is increased. This allows a player to use a single blueprint to hold a series of calculations in a single combinator entity, and reconfigure as or if required. (A numeric up-down box in the combinator interface allows the player to specify the number of active slots up to the maximum available. This could also be controllable by circuit signal.)
The slot increase between each level of combinator quality should be large enough to justify the expenditure of quality resources - perhaps a geometric progression. Legendary combinators should be capable of absorbing the functionality of a large number of normal combinators. This would be in keeping with the interpretations of quality as a means of extracting greater productivity per building tile ("factory must grow"), or, quality as a means of condensing existing productivity into a smaller space ("factory must shrink").
Whilst not explicitly part of this suggestion, constant combinators could also be affected by quality such that the number of active logistic groups signals output by a constant combinator would be determined by its quality, perhaps at a more forgiving level than for decider and arithmetic combinators. Similarly, quality programmable speaker, power switch, display panel, and lamp could also provide multiple behaviours for multiple separate conditions. Selector combinators present a different set of options but could still benefit from parallel and/or chained calculations.
ADDITIONALLY: to further expand the number of active computation slots or logistic groups signals in a single combinator, particularly at lower qualities, entities could provide module slots to increase parallel processing capacity. The number of module slots in a combinator entity would increase with the quality of the combinator. Whilst productivity, efficiency, or quality modules would be conceptually sound (with active slot increases reflecting the level and quality of the inserted module), a new type of module ("capability") could also be made available for this purpose (see postscript). A legendary combinator with legendary capability modules would have a functionally unlimited processing capacity, well beyond the needs of all but the most extreme circuit implementations.
As Factorio's complexity increases, logic-driven automation becomes increasingly useful for many players, and large arrays of combinators are not always practical or desirable. Increasing the effectiveness of the existing basic combinator types would help facilitate this.
----------------------
Postscript: "Capability modules" would be a general purpose addition to expand the primary function of a given device which currently does not accept, or would not logically benefit from, one of the four existing modules. I may turn this into a separate suggestion.