How is relative info actually converted from original info, if not by subtraction?
I cannot emphasize this enough, so I'm going to start with it: subtracting two Euler values does not give the rotation needed to turn one rotation into the other.
Now, the actual question, how are the relative rotation values derived?
The rotation of Suzanne here is turned into a rotation matrix (see wikipedia "rotation matrix".) Conversion to a matrix allows it to-- is necessary to-- convert that rotation into a different space. The matrices of all of an object's parents are multiplied together to provide the final, world-space rotation matrix, which is then re-evaluated in the space of the GN object. That converted matrix is then decomposed, reverse engineered, into XYZ Euler rotation values. That's how they're derived.
The process of converting Euler values into matrices means that some information from the original rotation values are lost. For example, values outside -180,180 are remapped to inside of that range:
720 degrees of rotation in a single axis is the same orientation as no rotation at all, so we see 0,0,0.
Less intuitively, many orientations inside -180,180 can be described by multiple Euler values. The precise Euler values used to create the rotation are lost, and are recreated by Blender according to whatever method it prefers:
We're inputting XYZ 0,180,180 and Blender is reading back 180,0,0. They happen to be the same orientation; once we convert it to a matrix, Blender only knows the orientation, not the values used to create that matrix.
These objects are unparented. When we rotate Suzanne, we see the values change; but when we rotate Suzanne and the cube together, we won't. (Well, not beyond small precision issues.) When we rotate those objects together, Suzanne's rotation exactly counteracts the rotation of the space in which we're measuring that rotation:
In addition, even though I have been showing the values in the sidebar with unparented objects, transform values are measured in local space. When we parent an object and rotate its parent, the object may have rotation relative to the GN object without having any local rotation:
Suzanne has no local space rotation-- that is, she has no rotation relative to her parent. But her parent has rotation. Thus, she has rotation relative to the rotation of the cube. She has inherited rotation from her parent, which doesn't show up in the sidebar.
In many cases, an object can end up hidden rotation contained in its "inverse," a hidden matrix that measures the relationship of an object to its parent. Depending on how parenting is established, an object may appear to have no rotation relative to its parent, yet still have transform values.
Now, let's get into the gravy of why subtracting Euler values is not the same thing as relative rotation.
Eueler rotations are three sequential rotations. The output of those rotations depends on the order in which we make those rotations. That's why there are six different flavors of Eulers: those are all the different orders that we can perform three rotations.
We can think of an Euler angle as being three rotation matrices, multiplied together. [x][y][z] represents an ordered rotation about three axes; the matrix multiplication product of those rotations gives us our final orientation.
Let's go back to unparented cube and Suzanne, to avoid complications with local vs. world space. [xC] is the rotation, in the X axis, of our cube; [xS] of Suzanne; [xD], a rotation, in a single axis, of the difference of those values. And we have those for y as well. We'll skip z, it doesn't matter.
Now, what happens when we [xC][xD][yC][yD]? We get Suzanne's orientation. [xC][xD][yC][yD] = [xS][yS]. But, what happens we [xC][yC][xD][yD]? We are rotating in a different order, and we get a different orientation. It will no longer be Suzanne's orientation.
But there are values that would solve for that. Rather than providing you xD etc, Blender is providing you x?, such that [xC][yC][x?][y?] = [xS][yS].