...

I guess I'l finally include it, but it'd be so much nicer if we could

...

find a conclusive use case. I've also thought about legacy interfaces

...

requiring raw pointers, if only we could come up with a simple specific scenario on that line.

Here's a case that is kind of an inverse of the legacy case: I sometimes develop DLL's in windows that are used by a team of C delveopers. I feel free to use C++ (including boost.multindex) in the implementation of the DLL, but the interface is straight C. Part of that interface may give out an opaque pointer to an object owned by a boost.multiindex. /* C interface */ typedef struct FooTag Foo; Foo *makeFoo(int x, int y, int z); void killFoo(Foo *); void flushFoo(Foo *); void flushAllFoos(); Latter they call in with that opaque poitner as a parameter. I could look up the node in the container, but iterator_to would be better. I don't consider this "legacy" because I'm writing a new library to support new development, but I am contrained by the interface language ("C" vs "C++"). Paul