Ned,

> I think Roel's concerns have to do with such things as UI tools like 
> browsers and assistants. Similarly to what we have discussed about 
> using some object to which we can delegate UI notifications like 
> #inform: and #confirm:, we could have one or more objects that 
> collects such notifications on compilation or other important events 
> and then dispenses them to its subscribers when it's safe to do so.

Okay, then that's the problem about knowing "when it's safe".

> So there could be one for the Morphic clients that would work 
> synchronously with the world update cycle; perhaps another default 
> one that would just discard the notifications, etc.

I don't quite see how this helps, in fact I think it makes matters worse. If
I test something in the presence of the "Morphic cycle dispatcher" I will
write code under the assumption that everything has been done already (e.g.,
the operation completed atomically) and if you change this to a synchronous
callback everything may break. In this situation you really want to have
_one_ policy and not a variable number. If you know that the callback is
going to happen synchronously then at least you know that you may break the
system and can test for those cases. It may be fragile but it's certainly
better than a situation where you run all your tests in morphic and then
ship headless - boom!

Cheers,
  - Andreas