Do we really want to be defining a type rbtree like this? The existing code is explicitly set up to be usable by the backend in such a way—cf. the "bytecode_offset" member—and sm4 types (and I think also sm1) are similarly supposed to be deduplicated, we just don't because it doesn't actually matter.
I'm not sure the answer is "no", mind. There's something to be said for orthogonality, and if we're going to be shoving things through vsir then we should maybe try to avoid hlsl leaking through so much. [Although on the other hand, if we're shoving things through vsir then how *do* we build reflection data? That's an unsolved question.] But I'm not sure the answer is yes either.
Either way, do we really want it to be an rbtree? It doesn't seem likely we'll have enough types to matter, and rbtrees are broadly just more work to deal with than an array or list.