Bob J.,
Without JMRI Java code changes, differentiating something like "held, but would be clear if not held" from other "held" aspects would indeed be impossible to differentiate via watching the DCC Extended Stationary Decoder (or equivalent) traffic on the communication media.
With code changes, and signal system definition changes, one could include "Held-but-would-be-clear", "Held-but-would-be-Approach", etc. as unique aspects with unique DCC Extended Accessory Decoder aspect numbers, in the signal system definition. That would likely cause follow-on problems, though, especially for any code that monitors signal aspect information to determine how to run a train.
At least in the common prototype "approach-lit" signal circuits I have seen, the "aspect" information is always calculated, and is always reported to the signal(s) protecting movements in the approach to the signal, regardless of its lit/dark state. Whether or not a given signal is lit is not reported to the signals in the approach to the signal. JMRI models this at the mast level, but it does not model this behavior as part of DCC Extended Stationary Decoder (or equivalent) aspects.
One could spend a LOT of effort trying to model these kinds of behavior as part of the JMRI signal system definition, the DCC Extended Stationary Decoder traffic, and the Extended Stationary Decoder configuration. And face all of the issues of "too few aspects" available in the DCC packet, and the coding issues associated with all of the other JMRI features that rely on signal aspects for proper movement of trains and calculation of signals.
Such a JMRI coding effort seems like too much effort for dubious gain.
Regards,
Billybob
