> It is the vast differences in the heap layouts of the sigc++ design
> which require what appeared to you as largely replicated code.
> (there are other many hybred designs like the one sigc++ 1.0 uses,
but
> those have additional problems we have yet to discuss.)

Just for the record, you've misunderstood me here. I understood that
design goals left sigc++ in a category of it's own, and that there's
compelling and valid reasons that the implementation should not be
based on the concept we're working on here. Those reasons aside,
though, there's no technical reason that the concept couldn't be
modelled using the concept we're discussing, only that it shouldn't
be. Blindly re-using basic tools with out consideration of
alternatives that may well fit better with your design goals is as
bad as never looking at basic tools for re-use.

Again, though, there are a lot of things that could be built with a
callback concept that should use a shared implementation instead of a
cloned one, but for which the full sigc++ is overkill. I think that
such concepts can be built using the cloned version of callbacks is
an important reason to choose cloning for the implementation.
Whether this will be done with a Boost version of sigc++ (if there
ever is one) or not is irrelevant to this point.