Dear Boost, One of the arguments against policy types stemmed from the subtle issue with things like `char_traits` and `Allocator` being template arguments: they spawn new types which may not be interopable. There is also the argument that "vocabulary types should be singular, concrete types". One of the great strengths and principals of C++ is having *decent* performance by default and choosing a default that most people can interop with (e.g., it is the safest or the most common vocabulary spelling) while letting users who care (which tend to be a lot of people in their own application-specific trenches) pick what makes sense for them. As it stands, we probably should have standardized a basic_variant<Policy, ...> and basic_optional<Policy, ....> before defining hard structs which inherit all member functions (struct variant: basic_variant<rarely_empty, ...> { /* */ }; and friends) to create sensible defaults for the community. At the cost of more up-front work, this would have saved us a great deal of effort and time in this domain by giving a decent default to interop with between libraries while giving the people with concerns for reaching the local maxima of their (private) ecosystems the chance to do so without rolling variant2 or optional.v3 or Yet Another Expected/Outcome Type. As a library developer, it's hard to not have just The One Variant Type because it makes writing APIs a bit difficult if you can't template on Policy. On the other hand, it's infinitely frustrating as both a library developer and an application developer when there's only one type and I only need to tweak some small bit of its behavior but instead have to roll an entirely new type and share absolutely no functionality with the original, let alone have the ability to create a reasonable constructor-based interop story. I think in the future we will start settling closer and closer to having customizable types where it makes sense. There's too much good design and performance and memory being dropped on the floor otherwise. Sincerely, JeanHeyd Meneide