If I get it right, your example doesn't work :
one timer would be one /msg, when you see +m, you pause them, when you see -m, you resume them and they would all execute their /msg command at the same time (assuming -m is set after all timer delay reached 0) because of that "bug".
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.
Not sure what you mean with this specific case but as I stated and if I get it ok, your example wouldn't handle that correctly
Edit : It doesn't matter anyway, you may have found one case where the actual behavior could be used, it doesn't mean that the behavior is correct.
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.
It's not about me, the problem has been reported five years ago, the actual behavior is simply wrong, it doesn't make any sense to use it as it is. Even for your case, noone would have used "paused timer" since noone would have expected it to work this way.
