Ok i will have to take some drastic changes because people keep reporting bugs about [Each] signal apparently changing the behavior. First i will keep a list of bug reports where this confusion was a primary factor:
First i will do a quick overview of signals that people in most of those cases want to use:
- [Everything] special signal used in a condition checks the condition for all signals that are present on the input. If every signal present (to be present it must be non zero) matches the condition then entire condition evaluates to true, otherwise it evaluates to false. If there are no signals to be checked it defaults to true (there were no contradicting signals so it is true).
- [Anything] special signal used in a condition checks the condition for all signals that are present on the input. If any of the signals present (to be present it must be non zero) matches the condition then entire condition evaluates to true, otherwise it evaluates to false. If there are no signals to be checked it defaults to false (there were no signals passing so it is false).
Now there is also a third special signal which flips the brain inside-out and completly changes the meaning of a combinator. It is an [Each] signal. Main purpose why this signal was introduced is to make it possible for a single arithmetic combinator or decider combinator to behave as a huge block of combinators, each configured for a different signal. [Each] becomes a substitute of a signal that has appeared as non zero signal on the arithmetic combinator input side or has appeared as non zero signal on the decider combinator conditions side. This effectively falls into a "stack of combinators" principle: if there are N unique signals on the input side, then combinator with [Each] will (in most cases*) behave as if there was a stack of N combinators connected in parallel, each one of them having a different signal put in place of the [Each] condition inside.
This "stack of combinators" principle effectively means that this:

- 11-05-2024, 20-09-13.png (65.25 KiB) Viewed 447 times
Is effectively the same as this set of 3 combinators where [each] signal was replaced with individual signals present on the input:

- 11-05-2024, 20-10-19.png (219.99 KiB) Viewed 447 times
Main point here is: If you are not an advanced circuit network user, you probably do not want to ever use [Each] as it will be confusing at first, and effectively never ever would you want to mix [Each] with [Everything] or with [Anything] in the same decider combinator.
Now with my points given here for other topics to link here, i can explain what is happening in the original post here:
- [Everything] = 0. is true so the output is given (decider is working in "normal" mode which effectively means it produces one output only)
- Each[G] < Each[R] OR [Everything] = 0. In this case obviously the second part is true, however that does not matter. Decider is working in "each" mode which means it produces output once for every signal that was used as [Each] substitute. Since N=0, that means the decider effectively behaves as no decider combinators because there were no Each signal substitutes and it correctly outputs value of 0. In this mode it is important that decider checks conditions for each signal separately because it matters for how many of the substitutes the conditions were true: output [check mark]=1 would give you a value of 5 if there were 5 substitute signals that made conditions with [each] to be considered true since it is an equivalent of having 5 deciders each checking individual signals and each of them tries to output [check mark]=1 into a shared output network.
Moving to Not a bug.
As for the [Each] signal, i will have to consider if i want to keep allowing mixed [Each]+[Everything] or [Each]+[Anything] as in many cases it simply does not make any sense, and i will also need to consider if [Each] signal could be renamed into something less ambiguous, like [For each].