The main problem with a policy-based type, such as a string type with many options (flex_string for example), is that different versions of the template are different types, and as such are incompatible.
This is a significant issue. A good illustration of the problem is the Allocator template parameter (call it a policy if you want) in standard containers. If I want to use custom allocator in my std::vector as part of a library interface, all user code is required to be templatized. The increase in physical coupling is not justified.
An obvious solution would be a type that can hold any of the template instantiations, and dispatch the member functions to the appropriate type through virtual calls, that could eventually use the stack like boost.variant.
Assuming that the additional flexibility you get with policy-based design is needed -- yes, that would be a solution. Often, a better approach is to design less flexible interface that better suits the problem domain. I compare policy-based design to a swiss army knife. If you really have o -- you don't have a proper knife, or scissors, or whatever -- indeed you *can* use it for all kinds of things.
An alternative would be to simply use typedef to choose the type you want to use throughout the program, which would somehow give source compatibility.
As far as users are concerned, using a typedef is exactly the same as using distinct types instead of a single policy-based template, except that a policy-based design would be more restrictive (for the library designer). Emil Dotchevski