I looked at this for an hour but just can't properly understand what is going on in this fix. I think we should postpone this for after 2.80 even if it's a serious bug, we risk breaking something more important.

What would help would be some code comments to clarify what each change is doing.

The T_EDIT changes are particularly unclear, whatever that is doing should probably be fixed elsewhere.

I agree the with T_EDIT thing. But the fact is that this is how it is currently coded in the other parts of the transform code too.

The reason to check for T_EDIT is that the transform values work differently in object mode and edit mode (I have no clue why this is a good idea or how this came to be).
In edit mode, only the first of the three transform channels are used. So if you have a X,Y,Z transform channel, regardless if you transform in Y or Z the transform amount will only be written to the X channel. This is then converted back into the actual channel:

Single channel transform value:

Object mode:
Input | Transform channel | Saved value
  X   ->      X          ->     X
  Y   ->      Y          ->     Y
  Z   ->      Z          ->     Z

Edit mode:
Input | Transform channel | Saved value
  X   ->      X          ->     X
  Y   ->      X          ->     Y
  Z   ->      X          ->     Z

This is one of many reasons I think that the transform code should be refactored/rewritten to not be a mess of spagetti code with strange special cases like this.
However for this fix, I just wanted to get it to work. So I copied the logic from the other functions to get it to work. And it seems to be working on my end.

It's just as you said very hard to understand what it going on and why. But I don't think this code addition will make it any harder. But I will of course add comments and change the current patch if you wish.

@Germano Cavalcante (mano-wii) @Campbell Barton (campbellbarton) Do you guys have any input on this?

I haven't tested it but at first glance it doesn't look like a dangerous patch.

Really the code is a mess, it would be nice to rewrite the parts that could be improved (as in this case try to unify the logic of object mode and edit mode).
One thing I learned from investigating the transformation code is that the final transformation is calculated on the callbacks in tranform.c (applyTranslation, applyResize, applyRotation ...).
During modal, t->values is like an input that is calculated from the mouse position. It can be a simple value, or a vector depending on the type of transformation (Scaling for example is a ratio while translating is a vector).
From the value in t->values, t->values_final is calculated and this is the value that will appear in the redo panel.

Your solution apparently was to change the calculation of the contrain matrix and set some properties to be read in the redo.
So to me it looks ok.