I don't think this will solve the problem. Even if you manage to get some TypeData for a type, if the TypeId does not match the TypeData will fail to downcast and call the given method on the concrete type. And if you use anything not based on TypeId (e.g. UUIDs) in there too, then it will likely be unsound, since you have no way to guarantee that if a type is changed (even transitively, e.g. one of its field types is changed) then its UUID is changed too.

These requirements would probably be part of the trait implementation requirements. TypeInfo and TypeData sets could probably be hashed and used to compare, but also there are places where using only TypeId for identification is not going to work. For example, if deserializing a set of data, a user wants to have something similar to an enum, but the set of keys is dynamic and based on what types are registered in a registry used for the de/serialization operation. Custom key types would be handy, and restricting it to type names and/or paths isn't making it much better.
TypeRegistration already contains a TypeId and could be used for checks. And if TypeIds don't match but the registry keys do, that might mean that the registration is from another binary/compilation and a conversion could be attempted using FromReflect and dynamic structs: clone_dynamic to get a dynamic struct from source data, FromReflect to convert to concrete type with expected TypeId.

Apologies if this comes off a bit chaotic. I might have only a set of specific applications in mind and also maybe some misunderstandings about the current reflect implementation and uses/connections.

TypeId is a sound identification type in one library, and this guarantee is provided by the rust compiler. But, when loading from another binary (plugin) or loading data from a serialized data set (scene), other identification types are needed. It may be possible to still keep these identifications sound, have checks. For example, by using some kind of footprint, that is encoding the properties of the reflected type. A stable type id that hashes even package versions, features and all of the compilation context would encode too much for the use case.
And it may be possible to create mappings from one id type to another. For example, to identify the type that is basically identical but in two binaries has a different typeid and potentially different data layout. If there is an identification type that works for signaling across these two binaries, a mapping could be made for each one. And when data inevitably has to go from one to the other, a serialized common representation of that data can be sent, then deserialized on the other end.

TypeInfo and TypeData sets could probably be hashed and used to compare

You likely don't want to hash TypeDatas, since they don't have a canonical representation (e.g. the function pointers inside them might be duplicated in different codegen units, so two TypeDatas for the same type might actually compare different).

TypeInfo contains TypeId so you're going to have the same problems as using TypeId.

And if TypeIds don't match but the registry keys do, that might mean that the registration is from another binary/compilation and a conversion could be attempted using FromReflect and dynamic structs

This cannot be done automatically on-the-fly when a TypeData is accessed, since it might be returning borrowed data or mutating the data passed in, and those won't work if you pass a temporary object that just got converted.

It might work if you perform this conversion the moment you create some type, essentially canonicalizing that type, but then you're just performing deserialization using reflection and type paths should be enough for that.

It may be possible to still keep these identifications sound, have checks. For example, by using some kind of footprint, that is encoding the properties of the reflected type. A stable type id that hashes even package versions, features and all of the compilation context would encode too much for the use case.

My point is that for many usecases this cannot be just a possibility, it has to be a guarantee or you have unsoundness.

I don't think this will solve the problem. Even if you manage to get some TypeData for a type, if the TypeId does not match the TypeData will fail to downcast and call the given method on the concrete type. And if you use anything not based on TypeId (e.g. UUIDs) in there too, then it will likely be unsound, since you have no way to guarantee that if a type is changed (even transitively, e.g. one of its field types is changed) then its UUID is changed too.

Personally, I'd like to know more about how we intend to support cross-binary types. Are we passing around raw pointers, utilizing the dynamic types, allowing specially-made custom dynamic types, serializing-deserializing, or something else? Depending on how this is done, "downcasting"¹ should be possible through type data.

In any case, it would be good to identify these particular methods so we can properly assess whether a generic identification system truly covers those cases, or if another solution needs to be explored.