Fair concern! The change doesn't make the device claim to be USB: its hardware id stays `WINEBUS\VID_xxxx&PID_xxxx` (not `USB\VIDsomething`), and it registers no `GUID_DEVINTERFACE_USB_DEVICE`, so nothing identifies or enumerates it as a USB device. Only its compatible-id fallback list gains the USB\\Class\_\* strings, which are the same ones a HID device's USB interface parent exposes on Windows (and that wineusb.sys already emits for the devices it enumerates).
No, the compatibility ID *is* what claiming to be a USB device is, at least from the kernel perspective. It means you can throw USB ioctls at it. The device name doesn't matter at all, at least it's not supposed to.
For binding: it still binds winehid through `WINEBUS\WINE_COMP_HID`, and no INF in the tree matches USB\\Class\_\* (I checked winebus, winehid, input.inf, mouhid, winexinput, but let me know if I missed any), so the new ids never participate in matching. The only in-tree code that consumes a USB\\Class id is an application running its own CM_Get_Parent / SetupDi check against the HID device's parent, which is the case this fixes.
Hmm, I guess if the winebus ID takes priority we should always choose winebus as the driver, so this should be safe after all. Although I'm not sure setupapi prioritizes correctly, but I'm less concerned about that for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11205#note_143718