Resolved XR Hands Package Only Support OpenXR Provider Implementation?

See https://docs.unity3d.com/Packages/com.unity.xr.hands@1.1/manual/implement-a-provider.html for a start. You'll need to implement this: https://docs.unity3d.com/Packages/c...erImplementation.XRHandSubsystemProvider.html (mentioned in the previous link). I need to add to the docs in the first link that in your loader, you should also store a XRHandProviderUtility.SubsystemUpdater (in the UnityEngine.XR.Hands.ProviderImplementation namespace) in your loader to create it when you create the subsystem, start it when you start the subsystem, stop it when you stop the subsystem, and destroy it when you destroy the subsystem.

Also, if you're passing the NativeArray memory for joints down to native code to get filled out (via GetUnsafePtr()) instead of creating them with XRHandProviderUtility.CreateJoint (also in the UnityEngine.XR.Hands.ProviderImplementation namespace), you'll need to mimic the source of XRHandJoint.cs in both struct order/sizing and the logic for treating the most significant bit of the ID field as a bool for whether it's on the right hand.

 

You're right that the encapsulation starts from Unity in C# for something like the hand subsystem, as opposed to in native headers and plug-in code like with the display and input subsystems.

There are two kinds of subsystems - those that can be defined in packages, and those that have to be defined as part of the core Unity product. The hand subsystem is the former, while display and input are the latter. There are some ways this affects writing a provider:

• For subsystems like the hand subsystem, all code is in C# until the provider uses something like the DllImport property to call into their native plugin. For subsystems like display and input, there's still a C# way of calling into the subsystem that Unity defines, but all code for a provider is native unless the provider decides to call into managed code on their own (not typically done, but I don't see the harm in it).
  
• A result of the above bullet point is that the interface you work with to provide data to the subsystem is in a different setup and language. For subsystems like the hand subsystem, you just need to work in C# to implement the provider and, where needed, call into your own native code - all definitions of anything you need to work with is in C#, and unless you're providing platform-specific data, you just need to worry about the provider type (the subsystemTypeOverride is entirely optional). For subsystems like the display and input subsystems, the corresponding interface is entirely in native code, in the headers you mentioned (IUnityXRDisplay.h, for example). The corresponding file(s) to IUnityFoo.h for subsystems like the hand subsystem are where-ever the package-writer chose to place it in C#, but you'll find it somewhere in the runtime folder of that package (Subsystem, Provider, Descriptor). The corresponding type to UnityXRFooProvider in an IUnityXRFoo.h that you need to implement as a provider is the XRFooSubsystemProvider type in C# for hand-like subsystems. There is no corresponding hand-subsystem-like C# version of an IUnityXRFooInterface, however - C# providers cannot call back into their subsystems like display-/input-like providers can.
• The way the descriptor gets registered - and therefore available in a call to SubsystemManager.GetSubsystemDescriptors<TFooSubsystem>() to find the descriptor you want and call Create() on it to get the subsystem - is different between these kinds of subsystems. For the hand subsystem kind, the way this is done is with a call to TFooSubsystemDescriptor.Register() during a
  [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)]-decorated method, (see https://docs.unity3d.com/Packages/c...provider.html#register-a-subsystem-descriptor). For the kind of subsystem that display and input both are, the way this is done is by having a UnitySubsystemsManifest.json that core Unity will read at start-up automatically to populate the descriptors itself.
• Also, there's no such thing for subsystems like the hand subsystem as something that corresponds to a separate RegisterLifecycleProvider call in native-land. The corresponding calls are in the base provider type (Start, Stop, and Destroy, while Create really exists on the descriptor).

Also, to answer another of your questions, there is no such thing as IUnityXRHands.h or anything like it due to this difference between kinds of subsystems.