The lazy evaluation makes an expression of the type A = A.transpose() + A evaluate to the wrong result. Sometimes the built-in checks in Eigen misses this. A simplified code example (compiled with gcc 4.6.1):
A << 1, 2, 3, 4;
//A = A.transpose() + A; // Causes a failed assertion in Eigen
A = A.transpose() + A + A; // Runs, but gives wrong result
B = B.transpose().eval() + B + B; // Correct
The result is A=3, 12, 8, 12 (wrong) and B=3, 7, 8, 12 (correct). When I run the commented line, I get a failed assertion, with the help text "aliasing detected during tranposition, use transposeInPlace() " "or evaluate the rhs into a temporary using .eval()", but when I add an extra term, it seems that Eigen doesn't detect the problem.
I guess detecting this would require a much more complex check than at the moment. Basically, as soon as the assignment is performed it is required to check if A appears transposed() anywhere in the expression (actually, one could check at the same time if it appears in a product or in overlapping block-expressions).
Maybe the expression evaluator will solve this one day ...
The goal of this aliasing detection mechanism was only to detect most common use cases, and we never claimed it was thorough. Detecting all nested transposed matrices would not be very complicated to implement, but 1) this would increase compilation time quite a lot, and 2) there exist many other aliasing situations that are much more complicated to detect (think about sub matrices or permuted sub matrices...).
Overall, I'm tempted to say "wont fix".
I agree that its almost impossible to detect all kinds of aliasing. I'd still think that an advanced alias-checker could be nice sometimes (maybe only enabled by a compile flag). But that would definitely be low priority.
Maybe we can postpone the decision until the expression evaluator is more or less stable and see how complicate it will be to integrate?