§6.3.2 of the provisional specification states:
Runtimes must ignore input source paths that use identifiers and component names that do not appear in this specification or otherwise do not follow the pattern specified below.
This forbids runtimes from supporting various devices that diverge significantly from traditional xbox controllers or Vive wands. For example, flight simulation (a popular VR application) equipment like the Thrustmaster Warthog or the CH Throttle Quadrant frequently involves large numbers of inputs that cannot be reasonably represented within the standard device input identifier space, both because it they involve unusual data types (like a 3-position switch, or digital dial with several discrete settings) and because the sheer quantity and placement of inputs exceeds the allowed possibilities.
While an extension could introduce new input types, it is unrealistic for devices like this to rely on the willingness of major runtime vendors to implement support for functionally device-specific extensions to provide input identifiers to serve an audience they may not care about. Although details on the device plugin layer are scarce, the quoted language suggests that devices will not be permitted to define novel input subpaths. This imposes a chilling effect on development of and support for input devices with form factors and individual inputs significantly different than those already widely adopted.
It’s unclear to me what the benefit of this restriction is. Applications cannot enumerate unbound input sources, and should not care about the structure of the paths to sources that are bound to its actions. As it stands, it seems that unusual input devices will be forced to make compromises similar to the ones made for compliance with legacy joystick APIs: imitating xbox controllers, presenting themselves as multiple devices, and abusing the intended semantics of the signals they produce. These make it difficult or impossible to use such a device with an application that was not designed with it in mind.
OpenXR’s abstract action paradigm has the capacity to solve the traditional chicken-and-egg problem of application support for unusual input devices by rendering applications insensitive to input device details. However, without allowances for device plugins to introduce input subpath locations and/or identifiers unknown to the runtime, and for runtimes to allow such inputs to be bound to actions, the problem will have only been moved into the runtime, rather than eradicated. Can we expect the device plugin interface to provide this capability?