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 :-)