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