I've spent quite some time playing around with the dynamic typing capabilities Rust offers. I found it quite interesting how far this can be taken, safely, if one is willing to handle complex type definitions.
But the article I wrote about it is already long enough, so I'll not write more here. Check it out if you are interested.
(I will gladly respond to questions and comments, although maybe a bit slow in the next couple of days. )
TL;DR. I'm not sure at all what the "untapped potential" is. Your TypeId-based collection is already implemented in typemap. And this part seems incorrect:
In particular your argument about renaming parent modules does not apply, because one can create two identically-named types with identical members and layout in two different modules at the same time, and they would then appear to be the same type. That is bound to cause errors.
As a follow up to this, you also can't rely on their layouts being the same, which means you can't use UniversalId as a straight replacement for TypeId without extra layout guarantees.
I'm completely with you, if the module is not part of it, it will cause pain. That's why a bit further down, I argue that per default, the modules should be used as namespace, which is going to be part of the string to be hashed.
I think there is still a use case for changing the namespace at will. But I admit I have to think it through more to come up with a decent design.
For UniversalTypeId, I assume no namespace sharing, which should be understood as always the default namespace is used. I think this should resolve the problems you're correcly pointing out.
I finally have access to a PC again. I decided to address the points raised here in a small update to the article. (Diff can be viewed on Github) Thanks for the valuable input!
Also, I noticed I missed to answer one question.
Yes, there are many implementations of this concept. I believe this also exactly what TypeId was meant to be used for, so I claim no innovation for anything in section 1. It is only there to explain the concept to readers who are not familiar with this already.
I called it untapped potential because I think we can apply this more widely. Such as library-based dynamic object+method dispatch, as discussed in section 2. You could build that on top of typemap but as far as I know, nobody has done it, yet, hence untapped potential.
With section 3, I show the limits of TypeId and I discuss options how they could be lifted, which would eventually lead to more potential use cases.
I hope that makes sense. Next post, I'll try to keep it shorter, which is always easier to follow.