I'll just keep spitting out info until someone gets a brilliant idea ;-)

http://elec.tric.nl/~cg/delay2.dump.txt (Unix LF terminated format)

I created a little bit of code that dumps all processes when something
goes wrong, and this dump has two processes inside the critical
section of Delay>>schedule.

One starts on line 453 ('a Process in Process>>suspend').
One starts on line 90 ('a Process in nil').

If you look at it, there's one funny thing. I added an #on:do: handler
around the actual addition to the "SuspendedDelays add:..." bit in
Delay>>schedule:

....
[SuspendedDelays add: ActiveDelay] on: Error do: [:ex |
		Processor dumpOnFile: 'delay2.dump'. self halt]

If you follow the stack frames from line 90, you'll encounter this
#on:do:. However, if you do the same with the other process, there's
no stack frame for the exception handler. the Delay>>schedule frame
directly calls the SortedCollection>>add: frame.

I checked, double checked, and checked again - this happens every time
I get this bug in my image (available on request ;-)), it happens
currently quite soon after I fire up the wx-based program, and always
one of the processes - which can be different processes - misses this
stack frame.

Could it be that I have somehow two copies of Delay in my image? Which
share the ScheduledDelays collection but not the Semaphore?

This is sooo crazy, it must have an easy solution :-)