I do agree with you about the fact that good PBD should provide orthogonal policies, but the fundamental use for PBD is to delay implementation details to when they are needed,
It's only a side effect. Fundamental reason to use PBD is to introduce granulation into your solution moving toward: one entity - one task principle
allowing easy to create and maintain yet flexible and extensible implementation. IMHO two policies (one for timer and one for logging) is more than enough for a profiling tool, how to collect data, when to report it how to report it, what estatistical analysis should be used are all policies for the logging policy, not the profiler.
And how does making logging policy parameterized with components simplify your design?
Some simple reports like "foo() - 50% - 10 ms" are usually more than enough for simple tasks. LetŽs save the big guns for the big tasks ;)
We already have boost::timer for simple tasks. I don't see how 4 policies make design more complex (IMO vice versa). And in any case correct design is better in long run. Gennadiy