Floor / Annotations / Clip and Positional Tracking seem quite different settings. I would put Positional Tracking right under Start VR Session, and move the others to another panel.

Is "Custom" landmark really needed, why not always uses camera objects? Setting up a location and angle without any visual indication seems hard, I'm not sure when you would use this. It could be copied from a camera, but then next users will want landmarks visualization and editing, and then to it seems simpler to just always use cameras.

For shading settings, it seems like you have to set them up blindly and then hope it looks good once you jump into VR, or switch back and forth to get the settings right? I'd expect them to be copied from the 3D viewport by default.

For the Viewport Feedback panel, name the options "Show VR Camera" and "Mirror VR Session"?

In D7100#169506, @Brecht Van Lommel (brecht) wrote:

Floor / Annotations / Clip and Positional Tracking seem quite different settings. I would put Positional Tracking right under Start VR Session, and move the others to another panel.

An issue I saw with having the positional tracking toggle right under the session toggle was that it would make it easier to accidentally stop the session. But with a separator in-between it might be fine.

Is "Custom" landmark really needed, why not always uses camera objects? Setting up a location and angle without any visual indication seems hard, I'm not sure when you would use this. It could be copied from a camera, but then next users will want landmarks visualization and editing, and then to it seems simpler to just always use cameras.

I can imagine that they are useful in some cases. We were thinking about a "Set From Current Pose" button, but I'll leave these small things to others to implement. Commented out the code for custom landmarks for now.

For shading settings, it seems like you have to set them up blindly and then hope it looks good once you jump into VR, or switch back and forth to get the settings right? I'd expect them to be copied from the 3D viewport by default.

The VR view uses its own shading settings currently, they can also be changed during a running session. The use case of milestone one is that the VR experience is controlled by a different person than the one with the headset on, so this should be fine.
We do however plan to have an option to share shading options, we'd probably enable it by default. Added to the TODO list, T71347.

For the Viewport Feedback panel, name the options "Show VR Camera" and "Mirror VR Session"?

Done.

In D7100#170035, @Julian Eisel (Severin) wrote:

The VR view uses its own shading settings currently, they can also be changed during a running session. The use case of milestone one is that the VR experience is controlled by a different person than the one with the headset on, so this should be fine.

For that use case, I would expect the person controlling VR to set up the shading beforehand for the most part? And even if you do it with another person, it's still rather blind, it's just that the other person can tell you if it looks good?

I think the concept of there being shading settings specific to VR is problematic. There are different uses cases for artists working on a scene and someone demoing a scene to another person. We have per-viewport shading settings, and per-scene shading settings for those. I just don't see why it should matter if the demo is being done in VR or not.

If you want to set up a demo for someone, why not just change the scene render engine to Eevee or Workbench and set viewport to Rendered?

To me it seems like this would simplify the implementation and make it easier to set up.

Noting some basic Python stuff.

All comments should be addressed by now and no bigger concerns were raised about the code. It's unclear from the last comment if Campbell did an in-depth review or just a brief check, and if he planed to have another look. This add-on is part of a 2.83 goal for which we go into BCon2 tomorrow. I'll have to use common sense and assume this is fine to commit. I think usually we aren't that strict about what we allow in the Add-ons repositories.

is it in the roadmap to expose the inputs in a generic way to python?

like 

import XRTools
headTransform = XRTools['Head'].matrix