Initial equations involving records are not handled correctly by the NF

[casella]

Consider the following test model

model TestRecordParameter
  record R
    Real x;
    Real y;
  end R;
  
  parameter R r1(x = 3, y = 2);
  parameter R r2 = r1;

end TestRecordParameter;

the NF correctly flattens it to

class TestRecordParameter
  parameter Real r1.x = 3.0;
  parameter Real r1.y = 2.0;
  parameter Real r2.x(fixed = false);
  parameter Real r2.y(fixed = false);
initial equation
  r2 = r1;
end TestRecordParameter;

but then the back-end fails to split the initial equation into its constituents

Initial Equations (1, 2) 
======================================== 
1/1 (2): r2 = r1   [dynamic |0|0|0|0|] 

ultimately leading to C-code compilation failure.

If I now try

model TestRecordParameter2
  record R
    Real x;
    Real y;
  end R;
  
  parameter R r1(x = 3, y = 2);
  parameter R r2(x(fixed = false), y(fixed = false));
initial equation
  r2 = r1;
end TestRecordParameter2;

with the NF, I end up exactly in the same situation, while with the old FE
-d=optdaedump reports

Initial Equations (2, 2) 
======================================== 
1/1 (1): r2.x = r1.x   [initial |0|0|0|0|] 
2/2 (1): r2.y = r1.y   [initial |0|0|0|0|] 

and the model simulats correctly. Apparently, there is something wrong in the way the NF is passing initial equations involving parameter records to the backend.

Among others, this issue affects all the 12 Modelica.Thermal.FluidHeatFlow models, see e.g. ​Modelica.Thermal.FluidHeatFlow.Examples.OneMass

[perost]

Replying to casella:

Apparently, there is something wrong in the way the NF is passing initial equations involving parameter records to the backend.

Fixed in c5af5c1d. The old frontend actually splits the equations, you can see it already in the flat model. The issue was that the NF didn't split the equation while also not adding the record constructor to the DAE. I fixed it by also checking the types of equality equations and assignments when collecting functions.