Boost.PolyCollection can be extended to use Boost.TypeIndex in RTTI-challenged scenarios. Taking this idea further, it is not unusual that some environments (game engines, for instance) provide their own RTTI framework: an even more ambitious extension to Boost.PolyCollection would then be to make it configurable for user-provided RTTI through some sort of traits class specifying replacements for std::type_info and typeid.

boost::base_collection requires that stored objects be MoveConstructible and MoveAssignable; unfortunately, it is customary to restrict copying in OOP hierarchies to avoid slicing, which would force users to revisit their class definitions in order to use Boost.PolyCollection. This can be alleviated by offering a configurable traits class where copy and assignment can be defined externally

template<typename T>
struct copy_traits
{
  void construct(void*,T&&);
  void assign(T&,T&&);
};

with default implementations resorting to regular placement new and T::operator=.

C++17 introduces parallel algorithms, like for instance a parallel version of std::for_each; it is only natural then to provide the corresponding Boost.PolyCollection-specific algorithms. The segmented nature of polymorphic collections makes them particularly amenable to parallel processing.

Closed polymorphism is a kind of dynamic polymorphism where the set of implementation types is fixed at definition time: the prime example of this paradigm in C++ is std::variant. Although boost::any_collection<boost::mpl::vector<>> can act as a sort of replacement for std::vector<std::variant<T1,...,TN>>, this is in fact more similar to a std::vector<std::any>, and a collection class boost::variant_collection<T1,...,TN> could be designed to better model closed polymorphism and take further advantage of the fact that implementation types are fixed (for instance, internal virtual calls can be completely eliminated). From a conceptual point of view, this would require introducing a new ClosedPolymorphicCollection notion and renaming the current PolymorphicCollection model to OpenPolymorphicCollection.

Users have expressed interest in polymorphic collections where elements are kept ordered within their segment and optionally duplicates are excluded, much like boost::flat_set/boost::flat_multiset do over their internal data vector. The open question remains of whether these collections should also guarantee some order between segments (current ones don't) to allow for the definition of container-level operator< and related operators.