It looks like the timer is doing things "by design" but the end users are assuming the vernacular meaning of timer, and puzzled by how these timers behave differently. It looks like what the timer is really doing is recording the ticks value when the timer begins, then all behavior is pivoting from that starting time. It internally keeps track of how many reps have happened so far, then calculates the next trigger time based on that calculation. So that explains why the .secs value seen inside the timer during the final execution is [delay-1] or [delay-0] - because it's assuming that itself will execute forever, and it's only after that final execution finishes where the overhead cancels the timer.

People think interval means a duration between the executions, when it really means [beginning_ticks + N*X]. So the -P behavior was mis-behaving for later ticks because, instead of keeping track of the ticks duration the timer had been paused ($ticks-when-resumed less $ticks-when-paused), and adding this to the beginning-ticks, after being resumed, the beginning ticks was adjusted to a calculated value relative to the next execution time, and the .delay was then changed to become the .secs value as the timer was paused.

This also turns out to finally be the only situation where I can see the -c catchup switch doing anything except behaving as if you used an invalid switch when doing "/timerX1 -c" after launch. So instead of displaying an error message that -c in this context was not valid, it displays the matching timers as if you didn't use the switch at all. Now I see that -c is only valid when starting a timer, same as the -i or -o switches. If the timer were launched using the -c switch, then if it's paused with lower-case -p at start+12 seconds then resumed at start+61, then all 4 executions of the timer happen immediately.

So what the -p was doing for the 2nd interval in the original example was trying to execute at the next available beginning_ticks+N*X ticks that's in the future. Then for the later intervals it continued executing at beginning_ticks+N*X ticks beyond that.

If I understand how the timer is working, then the expected -P behavior to fix like Westor wanted would be like a repeat of the code from my prior post:

Code:
//echo -a $asctime launch | timerx1 4 15 echo 4 -a $!asctime reps $!timer(x1).reps secs $!timer(x1).secs | .timerx2 1 12 .timerx1 -P | .timerx3 1 13 timerx1 -r | .timerx?


at ticks=001, timer starts with reps=4 and delay=15. It calculates that the next execution time is at ticks=15001.

When the timer is paused at ticks=12001 or shortly later, then resumes at 13001 ticks or shortly later, after resumation the timer should calculate how many ticks the timer had been paused, then add that to the beginning base-time, and also to the next-execution time.

Assuming the timer was actually paused for 1234ms, the beginning time would be adjusted to be 001+1234=1235 ticks, and the next execution time is 15001+1234=16235 ticks.

This would always cause the next-execution time to be in the future. The interval would remain at 15000 instead of being adjusted based on the .secs value when the timer was resumed. After the timer next executes, on or after 16235, it calculates the following execution time. Since the beginning time has increased by the pause duration, the next execution time should be targeted to be ticks=1235+15000*2=31235.

If the timer resumed after the original expected execution time of 15001 instead of prior, the resume calculation should be the same as above, except that it's merely shifting both the beginning-time and next-time by larger numbers.

As I see it, the -c switch is only used for either a timer using small -p which is then paused for longer than 1 [delay], or perhaps a normal time which was interrupted by a $findfile() of long duration.

For the capital -P timer behavior, the -c should not cause any difference in calculation due to a pause, but only in other freezes such as for a $findfile or a different program freezing mIRC for longer than 1 [delay] duration. The current -P behavior is correctly not adjusting due to using -c then pausing at start+12 then wait until launch+61sec to resume the timer.