OK - it seems to me that you've got everything covered. I'm anxious to try this out. I just have to figure a way to make it optional pending acceptance (or rejection) from boost. The "const" question isn't a big deal for me but I just like to you "const" every chance I get. I number of the static objects in the serialization libary are just to hold pointers to some template instantiations for unknown derived types so they could be "const". I now understand the static "internal type" instance. But it's very confusing when one reads the documentation. There's not explanation that it overloads the -> operator (other than the table entry in requirements. Given this I expect the synopsis to read static "internal type" *instance which one would expect to apply the -> operator to. Then there's the issue of using what looks like a public member variable as an interface. There are going to be complaints about this. I realize that these things could be dismissed as "cosmetic" - they are "cosmetic" - but going along with common customs and patterns makes it easier to grasp. So think about this. Tutorial - include an example of using this as an aditional base class in a multiple inheritance. This would not have occurred to me until it was probably too late but I think it might be very helpful to me now. Is there any way to test the claim that this thing keeps one instance even though the interface is used from mainline or DLLS. With serialization library it sometimes happens that users use a type in the mainline and the go do the same thing in the DLL. This results in two instances being created as the static initializer is compiled into each translation unit as a local function. This results in multiple typeinfo records corresponding to the same type.which could create some problems. I haven't figured out to use bjam to create a DLL in the same directory as the mainline test module so that this proposition can verified. Robert Ramey