Incorrect tensorField computation when using in-place transpose

Description

Summary

I believe there maybe a fundamental issue with field computation in v2306 and possibly also in develop (details below). I attach a very simple code that:

1. Defines tensor T1 as (1,2,3,4,5,6,7,8,9).
2. Computes:

T2 = T1.T();
T3 = T2 & T1;
T4 = T1.() & T1;

The results in T3 and T4 should be the same: the same symmetric matrix in each cell. But T4 is wrong. The field is not uniform and looks like a repetition of

(66 78 729 78 245 336 90 108 999)
(66 78 90 78 93 864 90 282 387)   

Background

I ended up checking this stuff because I was experiencing weird values in the nut values coming from the sigma LES model. I decided that I will reproduce each component leading to the computation of nut as per the code in the Ssigma function in here As you see, it involves gradU.T() & gradU and also G & G. I set out to do that with 2 different approaches. One is just writing a utility with a copy-paste of the code inside the function, so it will just dump the fields for a given timestep. The other was to add the computations as expression-based function objects in the controlDict so that I can have them at run time, perform averaging etc. What I ended up seeing is that I cannot get an agreement between the values produced by these two methods, and the discrepancy was in some of the components of the tensor G. I then realized that my G is not symmetric. This is when I started the analysis of the inner product.

I have also made tests in the develop branch and I get radically different nut fields from the sigma model when running the same case for 1 iteration:

As you see, the v2306 field looks strange, which was what originally prompted me to look into things. However, I am not convinced that things are fixed in developed, because the tensor G which I compute as

    G
    {
    type            exprField;
    libs            (fieldFunctionObjects);
    field           G;
    expression      "'grad(U)'.T() & 'grad(U)'";
    writeControl    writeTime;
    }

is still not symmetric (grad(U) comes from a grad function object)! However, the attached test-code does produce correct results.

Steps to reproduce

Compile the code and run in any tutorial, e.g. basic/potentialFoam/cylinder.

Environment information

• OpenFOAM version : v2306
• Operating system : Ubuntu under WSL / SUSE Linux Enterprise Server 15
• Hardware info : AMD CPU
• Compiler : GCC