Again, the "how" is the wrong thing here, it’s a trivial non-issue. The "why" is the problem.
The intended usage of `std::any` is to pass it to some code which checks whether the contained value is of some type which the code knows how to handle. It seems natural that code which knows how to handle some type, should also be able to handle all derived types. So, if some code asks the `any` whether it contains a `Base` instance, and any answers that it does not, when in fact it contains a `Derived` instance, this is arguably counterintuitive. Suppose we have a function:
```
void foo(Base);
```
We can pass instances of classes that are derived from `Base` to `foo()`, as long as `Base` is copy-constructible. And `foo()` doesn't need to know about any of the derived classes, only the caller needs to know about the derived class. Compare this to:
```
void HandleBase(any a)
{
if (a.type() == typeid(Base)) {
Base b = any_cast<Base>(a);
....
}
}
```
This function will only work for the base class. To make it work for derived classes we need to add to it checks for all derived classes. Not only is this wasteful, but it also means that this function needs to be updated every time a new derived class is added. Even worse, the definitions of some or all derived classes might be unavailable at the definintion site of the function. Allowing upcasts for `any` would allow us to write:
```
void HandleBase(any a)
{
if (a.is_a(typeid(Base))) {
Base b = any_upcast<Base>(a);
....
}
}
```
That's why I believe that the general direction of the proposal is not without reasonable motivation.