The current implementation seem to completely miss the point of this being a requested feature in the past.
I thought in the post this was a requested feature so we could (for eg) output the machine contents on one wire and the current ingredients on another wire. Separating input vs output was never hard to do an only needed a combinator to function as an isolator at the cost of a tick of latency.
Other conflicts of output signal usage exit as well and see no resolution of this issue in 2.1 or have I missed it?
2.1 Wire selection on assemblers etc
Re: 2.1 Wire selection on assemblers etc
Current implementation covers exactly as much as i was happy to add, no more, no less. I was considering per-option checkboxes but that was not acceptable because there was no sane solution available for gui that would not explode those guis beyond reasonable, and it would involve completly breaking lua api for interacting with control behaviors by script, huge amounts of migrations to try keep existing blueprints somewhat usable and even more migrations to keep existing saves loadable. Current approach is slightly less powerful but it was just enough to make it possible to get rid of magic-self-subtract that was part of 2.0 asteroid collector's set filter and assembling machine's set recipe, make it possible to have logistic container set filter and read contents both enabled at the same time while requiring almost no migration, introducing no lua api changes and also i was not impressed by any of the arguments about need for independent read of ingredients and contents of an assembler to be really that important, its always possible to just build a second assembler to read the ingredients for a given recipe.