I think this is not necessarily the right way to look at it - even free-floating anchors will have their poses evolve over time. If we want to make it so that they contain XRRigidTransform, we need to also specify a) what is the meaning of this transform (i.e. relative to which space it is expressed), and b) when does it get updated (since it will most certainly be changing).

It seems to me that the core spec will also have to be more precise about when native origins get updated if we want them to resemble something like a transform (I've added a comment on immersive-web/webxr#1071 that tries to pinpoint what the problems are). It may be easier to make native origins into a bit more fuzzy things ("handles that could be used when querying XR systems about poses" worked for me) instead of trying to make them into something concrete - I feel that if we want to make them into something concrete, we'd have to go all the way.

It's in world space. I actually should not define this as an XRRigidTransform, I should define it as a position and orientation in world space, good catch.

"handles that could be used when querying XR systems about poses" is fine as an interpretation! That's not functionally different from the status quo IMO, in the status quo the behavior of the handle is specified on the parent object.

The problem arises when you attempt to manipulate them, e.g. operations like multiplying an offset pose on a native origin to obtain another native origin does not make sense, and needs to be explicitly specced out. That is why I'm making these changes.

For some more context on the XRRigidTransform thing, really we use that type in internal spec text a lot more places than we should because we have no native "rigid transform" type. I would like to eventually fix that (w3c/csswg-drafts#4076)

I believe the core spec does not yet have the concept of world space (we do introduce something like this for test API though) & that it was by design (world space is not observable by the users of the API, some devices do not have a stable world space) - my main worry is there's a lot of things that we gloss over and it may get tough to close all those holes.

As for manipulating, I think the only thing we have been doing is copying the native origins around (to say that this thing should report same poses as some other thing). The same thing should be possible with your proposed changes so we should be fine here.

@bialpio yes, not having a stable world space is fine, the point is that native origins track real-world objects. The exact relationship with other real-world objects is not stable, and this is why the populate-the-pose has the language it does.

As for manipulating, I think the only thing we have been doing is copying the native origins around (to say that this thing should report same poses as some other thing). The same thing should be possible with your proposed changes so we should be fine here.

Yes, except copying them around is ambiguous (is it a by-value copy or by-ref? hard to say), and furthermore the original text was applying an offset to a native origin, which is weirder.

Typo?

(rogue { in line 1 - GH seemed to add my comment at line 2)

Nit: I'm slightly bothered by the use of "static" in "static origin", but as long as it's understood that this is something that may evolve even for anchors that are free-floating, we should be ok.

Hmmm, seems that we are missing a part of the semantics of free-floating anchors (it needs to track the real world) - see my comment below.

This causes me to raise my eyebrows - we need to ensure that static origin is something that is supposed to maintain its relationship to the real world (as understood by the underlying XR system). Other words to say the same thing - creating free-floating anchors should behave similarly as creating new "local" reference spaces with a pose initialized to something that the app passes.