To me point #3 is something we can fix with better APIs.
For instance, today it drives me nuts to have to write different patterns for and <2 x i16> and and i32.
Yes I should have the ability to discriminate on the type if I want to, but by default I’d like to be able to be type agnostic on these patterns.
My point is I strongly believe that the IR itself must be well typed but we can have quality of life improvements on top of it. (E.g., in that case, at the TableGen backend level expose a s32 type)