Dear all, While looking at some of my code that no longer compiles under the new tinfo() system I started wondering about the new system for return_type_tinfo(). As this system always was always more or less separated from the rest of the type system there is as such no reason to remove it along with the revision of the tinfo() system. In fact, this has serious disadvantages: Why do all non-commutative symbols automatically get the same return_type_tinfo-value? What if A and B represent matrices in the same space and C is a matrix in a different space? Should A*C*B not get simplified to (A*B)*C then? Same question for functions. Why is it no longer possible to define your own function with the same return_type_tinfo as, say, Dirac matrices of a particular representation label? The fact that in ncmul::eval it is necessary to check for Dirac/color objects indicates bad design. Although the tinfo()-system has, arguably, been improved the return_type_tinfo-system has been demolished. What about the following replacement? Make return_type_tinfo return something of type tinfo_t. In that case the user can generate his own objects tinfo_t as he pleases and e.g. dirac_gamma could take an argument of type tinfo_t instead of a representation label. Does anyone feel like implementing this or shall I do it? Best, Chris