The global interpreter lock is actually the cause of very few problems, and it isn’t the cause of this behavior.
If you schedule the routine for 1000 seconds into the future, and
.stop.reset it, certainly sometime in the intervening 16 minutes and 40 seconds the interpreter lock would be released (at least I hope so – otherwise your CPU would melt), but you would still see the noted behavior.
The problem occurs because you cannot remove a scheduled item after it’s been scheduled. The only way to prevent a scheduled activity from happening is to stop the clock (supported for TempoClock, not for SystemClock or AppClock). That would kill every activity scheduled on that clock. Usually you don’t want that, so the nuclear option is typically not preferred.
SC’s solution is to wake up the item as scheduled, but if the item is in a stopped state, to do nothing – including, don’t reschedule for later. It’s the lack of rescheduling that truly causes the task to become idle. It isn’t fully idle until that point.
If you stop and immediately reset, then the routine is first put into “stopped” state – at which point, to stop completely, it should be allowed to awake. But the immediate reset overwrites the “stopped” state and makes the routine ready to run on the next awake. So it continues.
A good case could be made that some complexity could be eliminated by implementing methods/primitives to remove items from clock queues. A better way to make the case would be for someone to actually write the primitives and put in a PR.