You're close.
I would do it with only two states and on any interactive object add a generic FSM with a global event called "RayHit" or something.
The raycasting should be done from a manager, or something on the OVR system that makes sense, but it really doesn't matter. You need to define where the ray starts from and shoot forward in self space - which you have. You're good there.
Now when you hit something with the raycast you can store the hit object and transition to a second state. In the second state you need to use Send Event, target the Hit Object, and send the "RayHit" event and add another Raycast just like the original, but instead of transitioning on a hit, use a GameObject compare to see if the Hit Object is the same as the one from the first raycast, or if its null. This basically means it will continue raycasting in the second state until it hits something different, or nothing at all in which case it would return to the first state.
You also need to send a "RayNotHitting" event back to the Hit Object so that it knows when you arent looking at it anymore.
Now what you have with this situation is a generic raycaster sending "RayHit" to any object it hits, on a layer mask of course, and now you can go to that individual object and add the RayHit event and do anything you want to it. You could use a template to do a generic rotate for the owner when this happens, or make each one unique, whatever you want here now.
I hope this helps and is clear, I've been really sick lately and kind of in a mind fog so this might just confuse you more lol. In any case, thats essentially the way I handled it and if you setup the raycaster to deliver the events correctly then its basically fool-proof.