1. Instead of providing the two options of deriving and embedding, let the user provide ADL-style 'next' and 'prev' lookup functions that for a given type provide hooks to the intrusive containers.

"I'm not sure about this, most of the difficulty is involved in manipulating the links" Yes, the access provided to the links should obviously be referential so the containers can freely manipulate them. " - iterator adaptor or facade can be used to easily create iterators for types with their own next and prev pointers." It's not the iterators I'm worried about. It's being able to provide uniform STL-ish access to all my current intrusive containes. Inserting and removing elements from such containers becomes a lot more consistent, I believe. "If there was a check that a node wasn't in a container on insertion wouldn't these problems disappear?" Yes, but I don't always want to pay for this check if my own program logic dictates that I cannot possibly be inserting an item that already exists. In my own code, we have an 'insert' and a 'safe_insert'. However, occasional refactoring turns an 'insert' using piece of code into something that should be using 'safe_insert'. I'd like to be able to temporarily turn on invariant checking for a list when I'm working on the code around it, so I can make sure my changes didn't violate any conditions. Regards, Jaap Suter