In other words, if you have an operation F, and two type aliases X and Y that both resolve to 'int' and you want F to have different semantics when applied to X and Y, you are effectively not using the C++ type system. You have imposed your own "logical type system" that is based on names (X and Y) and not types.

I understand, and to "effectively not using the C++ type system" I would add a subtle twist: "not effectively using the C++ type system" either :-). Yet there is lots of code out there that does this. So, with regards to intrusive_ptr, I guess the answer is that that kind of code is not worth considering when designing intrusive_ptr. Is it worth considering for the_next_boost_thing<T> ? Maybe it depends on the thing, but much of boost is generic, so I think it does make sense to talk about the_next_boost_thing, even out of context. Note also that things like map<> allow the predicate to be specified, instead of using a free map_less(T, T) and assuming map_less is always the same, for a given type. Now I understand that map is a different situation than intrusive_ptr - I'm definitely stretching things a bit. But I'm looking for reasons to use one technique over the other (and also instead of, say, virtual functions / runtime polymorphism, but I think I understand most of the differences there). Obviously passing in a predicate/policy is the way to go when it is reasonable to expect different policies/predicate used *on the same type*, and intrusive_ptr is probably a case where different policies don't make sense. Is that enough to make it better? ie: - a policy based add_ref for intrusive_ptr would allow it to be used in those rare cases where there is a 'type-overlap' or a 'lack of strong typing' HOWEVER, - a policy based approach would *also* allow different add_refs for a single type (ie 'logical' or 'strong' type), which would be senseless and *disasterous* when the type really only has one way of doing add_ref, THUS intrusive_ptr chooses free functions, over a policy-based approach ie we thought about a policy-based approach, but specifically wanted to *enforce* one-add_ref-per-type, or we didn't even think about it (at least not consciously), it was just the natural and obvious thing to do Anyhow, looking at it that way maybe teaches me something.... Tony