The important bit is to allow a single Routing Detector to distinguish between more than two states. It would pair well with the Analog Signal Controller Box for moderately complex builds and clean up places where we'd currently need multiple Detectors around the same Track.

This change should be possible without upsetting existing builds by modifying the routing table language to operate on nonnegative integers instead of booleans, but otherwise remain the same.

• Existing TRUE values would be replaced by REDSTONE_MAX (or somesuch--whatever would preserve existing behavior, even with mods that allow redstone signals > 15), FALSE would be 0.
• Leaf conditions would output one of these two values.
• AND and OR would treat 0 as FALSE and anything else as TRUE, but would evaluate to the same value as their last-evaluated argument (assuming short-circuit evaluation).
  • (AND 0 1) = 0
  • (OR 0 1) = 1
  • (AND TRUE 5) = 5
  • (OR TRUE 5) = TRUE
• NOT would return TRUE for 0, and 0 for anything else.
• Constant numeric values would be added as leaf nodes. It might be convenient to add TRUE (REDSTONE_MAX) and FALSE constants as well.

Example:

AND
Dest=foo
15
AND
Dest=bar
14

This would output a redstone signal of 15 for a destination starting with foo, 14 for bar, and 0 for anything else (no train present or other destination).

In the future, it might also be convenient to add condition nodes that output analog signals, or edit existing ones (e.g. instead of or in addition to Redstone=<true/false>, let Redstone read the current redstone input).

This need only affect Routing Detectors; Routing Switch Motors could just treat 0 as false and anything else as true. Another option would be to add a dedicated Analog Routing Detector, but according to #856, this would be less desirable.

The use case I have in mind is to make it easier and cleaner implement something like the behavior of Factorio's rail chain signals with multiple exit blocks. Suppose I have a single Locking Track at the entrance to a railway intersection, which I treat as a critical section (looking forward to #455...). A train passing through the intersection will be routed to one of several (let's say two) outgoing signal blocks based on its destination. But I'd like the train to wait at that entrance Locking Track until the intersection is free and until the outgoing signal block that it will take is empty, so I need to know which way the train will go while it's waiting at the Locking Track. This means that there are at least three states to be distinguished (no train, train present and wants to go north, train present and wants to go south), but a single Routing Detector can currently output only one bit. I can make it work by adding another Routing Detector, but this begins to look awkward and cause space issues. Plus, there are only 4 valid spots for detectors surrounding the Locking Track; one of them is already consumed by the source of the redstone signal to unlock the track; and placing anything in the air above the Track would be even more ugly for passing players (even if the Detector won't cause them to suffocate). And it would be nice having one fewer routing table to maintain.

I'd have to look at the parser to see how hard this would be to add, but I guess it could be done.

Closing since the pull request is merged.