> Meanwhile, does anyone else want to weigh in on this topic?

Just because you are asking I think that the model that the event framework
follows is fundamentally flawed. I tried to explain that to Rob long ago -
the problem you're discussing is ownership of the event/action pair. With
strong refs you say it's owned by the signaler, with weak refs it's owned by
nobody. Both doesn't work.

The only object that can really own it is the *performer* of the action
(this is somewhat similar to regular message sends where the receiver *owns*
the selector/method pair and the sender *knows* the name - in events it's
the signaler who needs to know and the performer who needs to own). In this
sense, the event is a trigger for a "method" (action) and if you think about
it that way then it's clear that neither the signaller nor any third party
can really own it. But it still needs to be owned by someone or else you'll
just randomly GC it.

In technical terms, the association between signaler and registration must
be weak (the signaler "knows" about the registration but it doesn't own it)
whereas the association between performer and registration must be strong
(the performer owns the registration). If done right (e.g., no hard
references from the registration to anyplace else) everything works just the
way one expects. In *all* circumstances.

The method/action metaphor also helps understanding about some other
consequences. For example, any arguments passed to the registration behave
like literals in methods - strongly referenced in order for the method
(action) to function. Deregistration is similar to removing a method - you
go to the owner (performer) of the thing and ask it. Changing the signaler
(removing the knowledge about the event from there) is similar to removing a
send site - the method (subscription) is still there (it's effectively
"paused"). Etc.

Because of the above, I'm pretty certain you will have more discussions
coming up about this in the future. Funny enough, the history of using
events in Squeak is quite interesting in this regard:
* first (I think) Stefan Matthias Aust wrote a first version - strong refs
* then I changed this - weak refs
* then John's version went in - strong refs
* then Rob changed it - weak refs
So now it looks we'll go back to strong refs. I wonder for how long ;-)

Amused,
  - Andreas

PS. The model I'm describing above is at the heart of scripting in
Tweak/Croqet. It's to no small part the reason why the multi-threading stuff
works after all - if I had to chase memory leaks, use explicit
deregistration or loose messages randomly none of it would work.