The basic idea is a good one, and the underlying tech (MLIR) is the right choice as it's an existing part of the LLVM infrastructure. The question, however, is

The basic idea is a good one, and the underlying tech (MLIR) is the right choice as it's an existing part of the LLVM infrastructure. The question, however, is why this particular IR implementation, given there are a number of ongoing efforts to do general C/C++ MLIR implementations. The urgency for upstreaming this change is a little weird, as i'd expect the community to take real time to investigate and think through the IR choices. I attended an LLVM conference earlier in the year, and they are a smart bunch with really deep understanding of this stuff, so I expect they will have opinions as to whether this is the right implementation, and whether this is the right time to adopt it. On a side note, one of the dangers of MLIR as far as I can see is an unfortunate side effect that optimisations performed on the language IR will not be available to other languages which use either LLVM IR or their or MLIR variant. This will either mean there are lost optimisation opportunities, or duplicate effort to port passes to other MLIR variants. That'll be a shame.