In looking through #440, I wonder if any non-trivial engine with an actual scene graph will ever make use of viewMatrix, or if transform is actually all they will evaluate each frame for all purposes, including positioning the camera in the scene relative to the app's chosen reference space origin.

As a case study, in the Windows MR native APIs, we exposed a similar member to viewMatrix: HolographicCameraPose.TryGetViewTransform(), returning you a Left and Right view matrix, each as a Matrix4x4. However, when engines like Unity get a hold of this each frame, they immediately decompose it into a position and orientation for the view, which they then apply as the world transform for their Camera's GameObject in their scene graph. At the end of the frame, the engine then just calculates its own view matrix from the Camera's final position and orientation, identically to how it would for a non-XR game where all camera movement is app-driven.

My own mental model here is that WebXR is not so much the first 10% of an opinionated XR render engine (e.g. dealing directly with view matrices, etc.), as it is a source of low-policy poses for tracked objects, such as viewers, input sources, planes, meshes and more. UAs can consistently deliver those poses (including viewer poses) as positions and orientations within app-created reference spaces, with engines then picking up from there to position their scene cameras appropriately, with the engine then calculating view matrices relative to their scene origin precisely as they've done for many years.

In that model, do we see a clear use case for engines to use viewMatrix without just decomposing it into transform and manually recomposing it before rendering anyway? If not, perhaps we should just remove the viewMatrix attribute and rename transform to viewTransform, defining it simply as you have here.

Originally posted by @thetuvix in #440