The changes I have performed has been in order to enable all material modes in some models.
Some background: Many models check the material mode and specifically implements some code for, e.g. 3D and PlaneStrain (and some trickier ones still do). By doing this, they can't support the default PlaneStress and the other material modes (like for the layered cross-section, etc.) because those relies on (iteratively) calling the 3D code and perform the reductions from the 3D output. This also enables new code that adds new material modes (like the recent "3dDegeneratedShell") to have full support without adapting any material models.
I did make sure that I broke no tests when I did these changes, but perhaps the tests were lacking (con2dpm.in and con2dpm2.in still seems to work in the test suite, and I haven't modified the tests).
I also strongly remember manually verifying the 1D-mode in con2dpm (could be mistaken, as I'm not in my office right now and can't check).
ConcreteDPM2 was probably the biggest out of those changes, so perhaps I missed some corner case.

These changes also enrich the export of IP values, as the correct tensor components are always printed for the reduced stress/strain material modes. VTKXML and the other export modules had no other choice than to just pad out reduced tensors with zeros.
It's not unreasonble to think that a complex model that implements 3D, plane strress, plane strain, 1d, could easily contain a bug in just one of these modes (partial stress control is not always that easy to implement in nonlinear models), and using the defaul t implementations that call the 3D code will always be correct (assuming the 3D code is correct). So it's not impossible that these changes might have inadvertently fixed a bug.

Could you share an input file (and if possible, smaller is better) that demonstrate the change in output?

--------

The "ddm" code is part of NRSolver (the engineering models don't touch this at all), and I can't think of any reason why this would have changed.
Looking back in git history,   the control_switch_1 test has always checked the components that happen to obtain a zero value (I don't know why, and it does seem like a test that could easily miss bugs).

I'll take a closer look.  If you have input files that you can share, that would speed things up.

Edit: I can't see anything wrong with "ddm". The second step in "control_switch_1.in" specifies "ddm 4 2 1 3 1 ddv 2 -2.5 -2.5 ddltf 3 refloadmode 0" and that seems to work (the values -2.5 seem intentionally set so that the total values should be zero, though setting them to something else gives the expected output)