Hmm, your edge case is correctly bugged then and your solution is useable, I had not considered bounding geometry around the overlap attempt. However instead of directly denying it there I made a new function “IsValidGrabOverlap” so that the filtering can be overridden further. Newest version of the template has it corrected.
However what it does is loop through overlaps and returns with the first one in order that collides/overlaps VRTraceChannel.
I had forgotten that the grab sphere now overlap with all geometry not just vrtracechannel, behavior was caused by that.
Currently? No, that actually would involve a surprising amount of re-coding of the entire character system, due to how ingrained floor detection and offsets are it would be even more of an overhaul than the VRCharacter already is. Let alone trying to handle cases like the head moving over an object that is below the neck and deciding if it should be the new floor for the player or not.
I had proto code for adding a second collider only around the head and running additional logic around how both capsules behaved, however the results were inconsistent and not what I was looking for at the time, also without integrated waist tracking I don’t foresee them being good enough to spend a large portion of my time on.
If using only “flight” style movement something of the sort could likely be achieved by setting the capsule height to something very small and adding to the VRCapsuleOffset in the Z direction to center the capsule around the camera. However as soon as a walking / ground based movement was introduced it would break down as it would find the floor off of the new location.
Sorry for late reply, your post got buried. It should already work as an interactible hud, you can directly load the server menu up in one and use the options (that is what I was testing with initially).