> Btw, what are the issues with doing the event notifications 
> asyncronously in their own processes?

Separate processes are not necessarily asynchronous. In this example, you
probably don't want to do something that just forks off a bunch of processes
and leaves it up to the clients to perform adequate synchronization. So even
if using processes might have advantages it is not necessarily asynchronous.
For example, doing something like the following:

notifyAll: clients about: anEvent
	| sema |
	sema := Semaphore new.
	clients do:[:aClient|
		[
			[self notify: aClient about: anEvent] 
				ensure:[sema signal]
		] fork.
		sema wait.
	].

is still completely synchronous. You merely wrap the call into a separate
execution environment which makes things slightly less problematic (but
basically only for cases that an exception handler could handle equally
well). But if any of the clients screws up the environment you still have a
serious problem in the above. The point of async notifications is that when
you "broadcast" the notification (signal the event) absolutely _nothing_
happens but only after all of the critical operations are completed and the
system is in a "known to be safe" state.

In order to indicate what a "known to be safe state" is you a theory of "how
the world works" and when things may or may not get scheduled for work.
Morphic has such a theory (stepping), so does E (VAT turn), so does Tweak
(script scheduling). This has been discussed in some depth when Roel made
the original proposal so you may want to look up a few of those messages.

Cheers,
  - Andreas