The awkward node constructor is not required. The TreeListNodeCollection already has a reference to the parent TreeList, so can't you just set the parent of each node when it is added, in the Add method?
Also, you can add the same node to the TreeList multiple times. I don't know if that is desirable (it could be I suppose), but right now all instances of the same node will be expanded/collapsed and selected at the same time. That is a bit strange I think. Not sure how you could handle that though, except not allowing the same item to be added twice.
No, I know, and that's on purpose. Don't you think it's useful? It's also why I implemented ICloneable. I considered it a feature, not a bug!
A big problem, though, is making a node its own parent, or making its parent its child. I'm having trouble figuring that one out, but I think I'll just let it slide for now. It's not a priority.
Yeah, modifying the TreeListNode collection is the next thing I'll do. I'm going to change it to be event-based, too, to give it less awkwardness, to give it more versatility, and to make it designable.
Finally, I'm going to add scroll bars (easy), arrows (easy), and I'm going to merge the Designer file with the code file because the designer file is useless. Coming soon!
I see. I can't think of any use for having the same node twice and having it mirror whatever you do to the other node, but someone else might so I suppose it's not a problem.
For the collection, why not inherit System.Collections.ObjectModel.Collection(Of TreeListNode) instead? For default implementation, you won't even need to implement or override anything, and it will behave like a strongly typed collection automatically. If you want, you can override four methods (SetItem, RemoveItem, ClearItems and InsertItem I believe) to do some extra stuff, like raising a 'collection changed' event.