It turns out if you produce an error in the :destroyed function, pretty crazy stuff happens. Of particular note is that the core doesn't actually go away when the destroy is called, but its images are removed and its health is set to 0. Worse, recompiles don't seem to affect the "ghost core," so you can have two cores on the same map with the same script, but executing completely different commands. This also means that if you create such a core, then accidentally hit "save" instead of "load" (yes, I've done it before, they're so close together!) there is absolutely no way to remove the core.
This is a contrived example, but it will reproduce the problem:
once
150 SetTimer0
endonce
GetTimer0 eq0 if
Self 0 Destroy
endif
:destroyed
0 0 500 SetCreeper
1 0 div
If you enclose only the Self 0 Destroy with a once block, it will also break the main game update loop. Fun!
I guess people should test their scripts thoroughly, but this seems to be a broader case than "delay in do loop with awake function" and far harder to 100% eliminate (dividing arbitrary variables etc.)
Yeah, the event handlers (like destroyed) were added in later rather than sooner and as such can have little issues like this. Next game, I hope to address some of these edge cases. On your specific example, the divide by 0 error is one I should be catching regardless of where it occurs.