I stumbled against this bug while I was trying to implement a surrogate of programmatic recentering, since the OpenXR API appears to lack such basic functionality (the equivalent of ovr_RecenterTrackingOrigin()).
If an XR_REFERENCE_SPACE_TYPE_LOCAL space is created with an XrReferenceSpaceCreateInfo::poseInReferenceSpace that contains a rotation, the window used by the runtime for asynchronous timewarp will be wrong for the XrCompositionLayerProjection that refers to such space. The perceived effect is that the limits of the visible (reprojected) area will be rotated off the view axis by the angles given in the space's origin orientation, to the point where nothing will be seen in the headset when the angles are too large.
Edit: To clarify, this occurs even if the rotation is yaw-only. Even though the OpenXR spec allows for any pose, it would be understandable at this point if the runtime was not robust to local space rotations that involved pitch/roll. But yaw should definitely be supported correctly.
Hey, did you check out my VR mods for No One Lives Forever 2
and Grand Theft Auto V