+1  A: 

Seems to me that there's a lot of things happening at the same time to keep proper track of.

I would try to separate the "disposal of objects" concern, for example add to-be-disposed items in a queue/disposal manager of some sort which would process (call Dispose on) items in a safer and more well designed/understood and deterministic way. If anything, this should help with debugging the problem.

_NT
An external 'Dispose Manager' might be a good idea (better then trying to handle this in the disposed object itself).Finding a good point in execution time to let the Dispose Manager perform its work might be a problem, since our code is called in events itself, and we are single-threaded.Hmm, I have to think about this timing problem, but it is certainly a good starting point to have a single 'registry of disposables, which could not have been disposed back then'.Thanks all for your suggestions!Cheers,Christian
7enderhead
A: 

You might consider a different approach if you just need a single listener that should dispose an object, perhaps a simple callback (implementing the Begin/End pattern in .NET).

Disposing of an event's sender isn't ever semantically appropriate: the object that created the collection (or initiated its creation) should be responsible for disposing of it, not an arbitrary observer.

Jeff Sternal
The problem is that the observer is the creator, but can only decide to dispose the collection once it contains a certain set of elements - of which it is informed by the event handler.
7enderhead
Isn't it possible for the code that creates the collection/observer to dispose of it?
Jeff Sternal
I will pick up _NT's idea of a Dispose Manager, which can do its work in the owning object.
7enderhead
@7enderhead: Could you mark the question as answered or add a point to my answer if it helps you?
_NT