Should XRRigidTransform.inverse.inverse return the original object?

[toji]

Question asked by @NellWaliczek on #560 (comment) Effectively, should to following code be guaranteed to evaluate to true?

let A = new XRRigidTransform(somePosition, someOrientation);
let B = A.inverse;
let C = B.inverse;
assert(A === C);

It wouldn't be a huge burden to retain the "parent" transform. There's possibly some minor memory concerns that would come along with that, but it's probably not a big deal. It may improve performance in some rather weird edge cases, but I don't think we should be optimizing for that.

I would be tempted to leave it up to the UA, but there IS a minor compat issue that would come out of it. The biggest functionality fallout of a same-object policy here would be that if someone patches an attribute onto the transform, and then calls T.inverse.inverse that patched value would still be expected to be there. I don't know if that's behavior we necessarily want people to be relying on, and as a result I would suggest not implementing this, but I do think it's worthy of discussion.

A related topic: Should XRRigidTransform.inverse return the same object every time it's called? That actually seems more logical to me, and probably yields real performance benefits in cases where the attribute is referenced multiple times, so I'd advocate for enforcing that.

[toji]

Nell and I talked about this some more. It seems pretty clear that the inverse getter should return the same object each time, and that's a 1-line IDL change, so we're going to do that. As for the inverse returning it's "parent" object, we found we didn't feel strongly one way or the other, so a vigorous round of Rock-paper-scissors concluded that yes, it should be the originating transform. ✂️