In many parts of boost, free functions are used as customization points for various things, better explained with examples:
   intrusive_ptr_add_ref()
   advance/increment/etc in boost iterator library
   etc

Are there other examples?

Now consider my example:
   template<T, U>
   myclass_assign(T *t, U const & u)
   {
      t->operator=(u);
   }

That forms the default implementation, but clients can define their own specializations (for cases where T is a simple type and not an object at all).
At first I thought that 'myclass_assign' should just be 'assign' since the assignment should be the same, just based on type (not on the circumstances of why 'myclass' is doing the assign), but (just while writing the email) I saw a problem there: in the case of, say:

typedef int RecordID;

assign(RecordID id, SomeValue const & value)
{
   // do the assignment
}

But of course, RecordID is just a typedef, not a 'strong typedef', so it could be just one example of many assign(int, SomeValue), completely unrelated to each other.

So how should that be handled? Specific naming (using 'myclass_') lowers the chances of a problem, but doesn't remove it. Which means that, in theory at least, intrusive_ptr has the same problem:

intrusive_ptr_add_ref(some_typedef_that_is_really_an_int)
{ ... }

intrusive_ptr_add_ref(some_OTHER_typedef_that_is_also_an_int)
{ ... }

Should myclass, and also intrusive_ptr instead use a policy-based approach, similar to boost iterator?

intrusive_ptr<T, policy = legacy_policy>
{
...
}

Is there some other approach that I'm not considering (ie runtime boost::functions instead of compile time policy functions)?

Tony