Are trigger connectors forward only?
Oooh, that's a tough one!
To be quite honest, I'm still not entirely sure - I have always assumed that's the case (for the same reason as you - no value to pass).
I have tried to test this for sure a few times now, including another little attempt tonight - but devising a test is not simple...
When a primitive returns a value in response to a 'backwards' trigger, it only ever sends the reply back along the same route as the request - and in this case, that would be back to a trigger input, which can't show you if anything changed! That's the big problem with reverse triggers, no way to see where they go - so tracking them is nigh on impossible.
The only way I could think of was to connect it up to some very big counters and arrays, and look for the CPU usage - but nearly all the really heavy duty stuff has a 'do it now' trigger input, precisely so that they won't get triggered by accident. It seems intuitive that these wouldn't do anything in response to a 'backwards' trigger - though I will be adding an 'exceptions to the rule' chapter at some point.
During the course of this, I did learn something else that needs a mention in that chapter... Even the array primitives without a 'do it now' trigger input do not generally respond to 'backwards' triggers - I haven't tested every single one, but it does seem like common sense that they are not updated every time something downstream is triggered.
But I'm no closer to an answer about trigger connectors. I tried testing with big nested modules of regular little maths prim's - but I got bored before I added enough to give a measurable dint in the CPU load (even on an Atom CPU).
Which may make some people wonder - "why go to all this effort optimising, if the CPU load is so small?".
A few reasons...
1) Triggering GUI ReDraws is not CPU friendly - I have had schematics where the GUI easily outstrips even the audio processing for CPU load.
2) Arrays and big loops will always be greedy if triggered too often.
3) MIDI events create triggers, and they can potentially happen much faster than mouse moves or the tickers (maybe a way there to answer Infusion's question).
4) Much of the reason I use so many trigger blockers etc. is to make a schematic behave more predictably, easier to understand, simpler to de-bug etc. If something is being triggered when you don't expect it, you don't need to search for the problem along links which have been blocked. Similarly, links which are blocked cannot be 'in the wrong order', which makes re-routing links much more predictable when editing.
PS) Although the tutorial is intended as a practical guide, I am planning to ask Malc if he'll proof read it some time, to check the technical accuracy, and see if I missed any other 'exceptions to the rule'.