Collections (or Lists) are interesting.
I think you should probably never store any property value in a collection.
A collection is a list of things of the same type (even if that type is 'Object' (i.e. any type)).
It should be nothing more than that.
If you are modeling a 'set of things in the real world' then create a class to abstract that list, and then give that class a property that is a collection of those things.
You should never have to 'serialize' a collection. You can serialize the 'thing that represents the set of things in the real world' and you can serialize the 'things' but you shouldn't have to persist any other state.
You can still have methods on your collections for working with state in any or all of the 'things'.
I'm not sure what I think of collections and external events, but I tend to suspect that this isn't 'business state' it's 'program state' (i.e. plumbing) so it's probably OK (because it has nothing to do with serialization).
It follows that a collection can never know 'who owns it' or anything like that. (In fact, a collection can know nothing that isn't contained in the list of things that it models).
Did everyone else already know this..? I've sort of realised this before, but I've never 'verbalized' it. (i.e. made it explicit).
This rule will help you manage complexity.
John.
It boils down to the fact that generally you have to be 'wordy' to say 'what you mean'!