yeah, I encounter the similar issue on Ubuntu 20.04 that claim the interface automatically. I used a simple script in python to detach the kernel driver. I think the reason they don't implement that feature is because it is different for different platforms and it touches a lot of low-level stuff for different platform, not sure if there is a general fix for that. I can confirm that you don't face the same issue on MacOS not sure on Windows.
Do you have any idea on how to solve the issue without touch the udev or running the python script like I did for linux?
I'm developing a tool to send usb data to the device for end users and I don't want them to go down to the low level such as that

There are two pieces to this,

1. When implementing WebUSB the principle we used to avoid introducing potential security issues was that it should not preempt the existing system configuration. The assumption there was that if there is a kernel driver then the system expects applications to use a higher-level interface provided by that driver instead of the low-level USB interface. There's some discussion in Chromium issue 40137537 about detaching kernel drivers on Android specifically which are known to be unused and thus that principle doesn't apply.
2. On platforms other than Linux overriding a kernel driver is much more difficult. For example on Windows it requires calling system configuration APIs that require administrator privileges and the effect persists across reboots.

Thanks, that's useful to know.

If Windows requires invasive action to relinquish control to the browser, I understand the answer to my question will be "claiming an interface should not be disruptive" for the foreseeable future. Thus I should redesign the device to use a vendor subclass.

Since the user has already performed an action to approve opening the device, taking a defensive position due to security seems questionable. But given the above, I don't think it matters.

My question has been answered. I'm guessing it doesn't need further clarification in the spec, though I think a note that this is intended behavior would be useful.