> We want to add a method called "get_base" to "std::any" to check if the contained object has a particular base class. That's one use case that more than one person has asked for. But in order to implement "get_base" in "std::any" without causing an ABI break, we need to get all the required info from the 'std::type_info'. So we need to beef out 'std::type_info' with what's available on Itanium and Microsoft.

1. Getting the type's size and alignment doesn't get you an inch closer to identifying a type that has been forgotten. You cannot use that information to distinguish between any other potential type that could have that same size and alignment.
2. There are more platforms than just Itanium and Microsoft. The fact that you can do it in those system is irrelevant. If the standard was going to do it, a compiler implementer can just add an extra sizeof and alignof without any hackery.
3. The standard defines a "what" and not a "how". You are trying to sell a "how", but what you need is a "why".
And you don't seem to get this, you are just spamming the mailing list, going around in circles getting nowhere, and you will never get anywhere. But you don't really care, you are not here because you have something genuine to improve, you are here because you think you have done something cool, and you need an audience to validate you.
4. Having a "get_base" wouldn't need to expand on "std::type_info", you just define that "std::any" has a "get_base" and each vendor will deal with the implementation details to determine what does that mean, which doesn't need to touch "std::type_info". The question is why? Why should I implement this?
5. std::any is a terrible class, it might have its narrow use cases, and I argue that it shouldn't be expanded upon. For everything else std::variant is better, an object can't possibly just be absolutely anything. It is far more likely you are using the wrong thing than the thing to be wrong.
6. "dynamic_casting" from void* is not a thing, and it will never be a thing. This is not an oversight; it's how it should be. It is just a consequence of data, you can't tell the difference between a pointer that actually points to something or an integer that is aliased to a pointer, or if the first address of the pointer is reference in a vtable or just an integer used for a completely different purpose, you don't know if it’s the beginning of an object, or the middle of one, or one past the end, or a difference, they all look the same. The only thing that distinguishes these apart is context, it's always been context, the "type" system is a system that keeps track of context not "runtime magical objects".
The only situations where you find void* being cast to something else, its because the developer knows from context what it is, and more than just that, there's a reason why that thing is there, and the system is aligned so that it is prepared to use it for its intended purpose. It is never a useful scenario that you just get thing that could be anything and expect to make use of it, for a purpose that is not even coherent.
And if you can't understand this very basic idea, you won't understand C++ (or C, or any low-level language for that matter).
If you are having trouble because you lost track of context, maybe you should get better design that doesn't do that instead of trying to change the standard.