If .secs is zero, this could mean that it is a /timer N 0 call and is going to execute at the next timer event, which will be in zero seconds - in other words, immediately. It does not mean that it will not trigger again. So a zero value cannot be used as indication of final execution. The .secs property is not meant to be used for that.
That's irrelevant. The claim is not that getting 0 can't mean it's a /timer N 0 call, it's that .secs returns the number of seconds left before the timer triggers, this is written in the help file. In OP's first example, .secs DOES NOT return that value in the last execution.
//timera 5 2 echo -s $!timer(a).secs
This much better example displays:
* Timer a activated
1
1
1
1
2
* Timer a halted
First (this is not the problem that was reported but I'd like to hear about this), let's note that '1' is incorrect here, when the scripting engine is running the /echo -s command, the timer has already triggered, or "it's currently triggering". If you consider it has already triggered (and there are repetition left) then it will trigger again in 2 seconds not 1 second, therefore .secs should be 2. If you consider it is still triggering and then it should be 0, the value 1 does not make sense.
However this is an old behavior which can't change: way too many scripts are already using $calc to do a +1 (which correspond to OP's -1).
Now what is being reported is this '2' in the output. This time, we are at the last repetition of the timer, so it does not matter what if you consider the timer to have triggered or to be triggering: the timer IS NOT going to be triggered again, therefore the timer is certainly not going to be triggered in 2 seconds, therefore .secs should always be 0 in this last repetition, which is the bug reported here.
