A good proposal needs to start with motivation. It needs to present
something that the current language cannot do, as well as explain why
it is important to be able to do that thing.

Your proposal does not. It says what you can't do, but it never says
why doing that would be useful. It merely assumes that everyone agrees
that we ought to be able to do that.

Your code example shows what it is you want to do, but it never shows
why that's useful. If some library throws an exception of a type you
didn't know it could throw, what *exactly* do you plan to do with that
type information? What are you going to do with that `std::type_info`
object you create?

Is this for printing out some debugging information? Are you going to
start comparing it to other `type_info`s and doing a bunch of casting
to figure out what it could be (which would be exceedingly pointless)?
What is the point of getting this information if there's nothing you
can really do about it?

As for your suggestion that we shouldn't be able to throw anything
that isn't derived from `std::exception`, again I ask: why? What would
that do which you can't do otherwise? The only functionality of
`std::exception` is that it carries a message via a `char const*`. But
even that could just be an empty string, so you are guaranteed
precisely *nothing*.

P1066 provides similar functionality to what you want, but that's
specifically about cases where you get an `exception_ptr`. While
`catch(...)` can get `exception_ptr`, so do many other interfaces.
That proposal is much more about being able to introspect
`exception_ptr` without paying the cost of throwing/catching it. It
has much better motivations (with actual performance metrics for the
current state of affairs) than your more limited proposal.