once a pose is initially established for a viewer or input source

Ok, so I see we're calling out these spaces as different than the generic XRSpace. Where do we define the behavior of the generic XRSpace?

So far, all we have are reference spaces (including viewer spaces) and input source spaces. As we later define anchor spaces and other spaces, we'd need to augment the spec if we decide they behave differently than today's spaces.

For now, I've just changed this to:

However, once a pose is initially established for a space (e.g. a viewer reference space or an input source's gripSpace), pose matrices should continue to be provided even during tracking loss.

My hesitation with this new phrasing is that pose data is always queried the same way (through getPose()) regardless of the type of XRSpace being located. If future types inherited from XRSpace behave differently under tracking loss, we could end up in a situation where developers aren't prepared to handle those differences. In other words, you're making the statement that the only time this should return null is during initialization and that once a pose is returned it will always be non-null, but I'm not sure we'd take that stance for anchors in the future. Am I making sense?

I'm not sure I can see why we'd ever return non-null; assuming there is some way to know that the tracking has stopped, continuing to return the last know pose is the only option that makes sense to me. If it's optional, we'll get a pattern where developers (and libraries) will just mirror that last known pose anyway, and use "null" as a "use last know pose" flag.

There are two paths we may ultimately take with XRSpace tracking recovery for future spaces:

• We do as @blairmacintyre says and just decide that for all future spaces, we might as well just keep returning a last-known pose once any pose is delivered, and so all future spaces just behave as today's spaces do.
• We decide that it's simply too wrong to claim that we have any notion at all of where an XRAnchor is relative to the viewer reference space if you've recovered tracking in a disjoint new room, and so we want to be hardcore and return null for just that new flavor of XRSpace. However, this decision won't surprise any existing apps - only apps that explicitly start using XRAnchor objects and their resulting spaces will ever observe the new behavior. It seems OK for apps that explicitly opt in to a new scenario through new types to start getting more nuanced behavior from existing types, which we'd document at that point.

While I'm tempted toward the latter behavior to help stop apps from doing silly things when rendering anchored content, I believe the former is more consistent and easy to specify, and apps have the bit they need to not render at anchors when they're not actively tracked. (and as Blair points out, a naive abstraction layer above WebXR is likely to just implement "null" as "don't change the scene object's pose" anyway, and so there's a limit to how valuable being draconian is anyway) However, whatever decision we do want to make later, I think we can do so compatibly, regardless of what we say now.

viewer

Is this phrasing compatible with the simplified spaces PR that just landed?

It seems compatible to me - the concept of viewer remains a first-class concept in the spec.

Why viewer and not reference space?

In general, a single space "having tracking" is a squishy shorthand for the well-defined notion of whether two particular spaces can be tracked relative to one another. I'm using that here in the explainer to get folks aligned with some digestible examples before we get specific in the following paragraphs.

When using that shorthand, though, I tend to find myself thinking of a viewer (e.g. my headset) as "having tracking", rather than thinking of my primary reference space itself (e.g. my floor) as "having tracking". While a viewer is a kind of reference space, being that generic here in this list of concrete examples felt like it would take away from readers grokking the overall concept.