Why the split into separate hover and select interfaces?

Just wondering the reasoning behind this particular change in the 2.0 version of the toolkit. I’m finding it’s making a lot of related code rather bulky and laden with type checks and casts, and I’m uncertain what advantage splitting it up like this provides over say just having a single interface for interactors, or just making all the methods of XRBaseInteractor virtual and protected (same for XRBaseInteractable).

Does anyone have a use case which might illustrate what the advantage of this approach might be?

I responded in another thread with some reasoning behind the change here: Filtering a socket by tag with new IXR interfaces? - Unity Engine - Unity Discussions

For users creating a custom interactor or interactable that only needed to support hover or select, they will not need to implement a bunch of methods, properties, and events unnecessarily. I believe one user used it to create a voice command interactor which could select interactables, but did not need to support hover at all.

Most of the methods in XRBaseInteractor and XRBaseInteractable already are public or protected virtual, so users can continue using those and have it support both hover and select.

You may already know this, but if you are unaware, you can use the C# declaration pattern to ease some of the casting or verbosity with using as. For example, if you have an IXRInteractable interactable, you can do this in a method:

if (interactable is IXRSelectInteractable selectable)
    // Do something with selectable

Are you able to share some examples where you need to cast which is making the code bulkier than before? We may be able to add methods or properties to help with your cases.