I have a lot of experience with libusb, libudev, and SetupAPI for writing Windows drivers, but it's totally unclear to me what CfgMgr32 offers over SetupAPI for Windows USB applications. Microsoft outlines how one would port from SetupAPI to CfgMgr32, but, I don't really understand the trade-offs or if there are gotchas.
Specifically, most of the time my work involves communicating to bespoke devices with isochronous endpoints, devices with bulk endpoints and HID devices. Is there any clear reason to do one or the other?
One reason is stated at the top of the Microsoft page describing how to port from SetupApi to CfgMgr32 found here https://learn.microsoft.com/en-us/windows-hardware/drivers/install/porting-from-setupapi-to-cfgmgr32.
Excerpt with pertinent part in bold:
This topic provides code examples that show how to port code that uses Setupapi.dll functionality to use Cfgmgr32.dll instead. Porting your code allows you to run your code on the Universal Windows Platform (UWP), which does not support SetupApi. A subset of CfgMgr32 is supported on UWP, specifically functionality exposed through the api-ms-win-devices-config-l1-1-0.dll API set (Windows 8 and later) or the api-ms-win-devices-config-l1-1-1.dll API set (Windows 8.1 and later). In Windows 10 and later, simply link to onecore.lib.
Another reason is that the CfgMgr API provides a specific return status code for operations whereas SetupApi returns a value to indicate success/error but a further call is required to GetLastError to get the specific error code of the last operation.