Ah ah really ? Can you give one example where it makes sense and where one could use the actual behavior ?
The current behavior makes since in certain contexts. For example, suppose you use a timer to queue a large number of lines to a channel (like /play). The only purpose of the delay in between sending each line is to avoid flooding. You may want to pause the output if the channel is set to +m, then resume when channel is set to -m again. After the -m, it makes more sense to immediately send the next line instead of finishing the delay (assuming +m was set for reasonably long).
At first glance this looks like the same as just stopping and starting a new timer (when +m and -m are set, respectively) instead of pausing and unpausing, but it's not. If +m was set and unset very quickly such that it is still too soon to send the next line, restarting the timer would cause a line to be sent sooner than intended, whereas the current implementation of pause/unpause will handle this correctly.
Now, the behavior you are describing would also be useful, but in different contexts. I don't think the current method is wrong, but just different than you expected. For this reason I don't think the current behavior should change but perhaps a second pausing method could be added.
