Is that what happens or is just the rest of the parameter being set to 0?
In the case of a promoted scalar value, it only sets up to the remaining 3 bytes of the promoted type. I.e. If there is more than 3 bytes remaining in the given parameter, then only those 3 bytes are set to zero and everything else is left intact.
I assume you mean the remaining 3 DWORDs. There's a good chance that parameters are internally handled at vec4 granularity (i.e. everything is made of a bunch of 4-element vectors) and individual vec4s are set "atomically".
As the test I just pushed shows, for matrices byte_offset can only shift the copied values up to 3 times. This is because SetRawValue() will treat byte_offset as an array index keyed on multiples of 4 (sizeof(DWORD)). I.e. Given a byte_offset of 3 with a parameter of int44, SetRawValue() will start writing to the first int (array[0]) but shift all bytes over by 3. A byte_offset of 5 however, will cause SetRawValue() to start writing at the *fifth* int (array[4]) and shift all bytes over by 1.
Could it be that matrices are stored with reversed majority instead (so like in the order ._11, ._12, ._13, ._14, ._21, ... and you're reading them as ._11, ._21, _31, _41, _12, ...)?