Oh, USB 1.1 at the transport layer and lower is not that difficult.
But there is more complexity on higher layers. USB HID (mice and keyboards) is often the first you'd want but it is special in that it allows a device to describe its own packet format in a tokenised data description language.
The device only has to send an additional blob when asked, but the host has to parse the contents of that blob and use the result to parse the device's packets.
And of course, every time there is complexity in a protocol and there are multiple implementations of it, there is more opportunity for them to be incompatible in very subtle ways.
This phenomenon has caused for example that some gaming keyboards with N-key rollover that work perfectly on MS-Windows without any special drivers have been rejected outright by Apple or Linux hosts. (I hope these issues have been fixed now, but I'm not sure).
I thought there was also a mandatory fixed-layout "boot" profile for mice and keyboards? There was some controversy because vendors interpreted it as only being allowed to support the boot profile, resulting in most USB keyboards having 6-key rollover maximum.
In a nutshell, yes. There's a flag for it (actually "subclass") for indicating being able to switch to the boot protocol.
Some hosts, especially BIOS:es, did check that flag but never sent the command to switch.
Keyboard vendors catered to the lowest common denominator because it was essential that users be able to enter the PC BIOS at boot.
BTW. Apple chiclet keyboards (before the "Magic") got an interested workaround to this problem for its proprietary Fn key. It uses a variation of the boot protocol but only a 5-byte array (5KRO). When the Fn key is pressed, the sixth byte will contain a code that is otherwise an error code if interpreted as the boot protocol.
But there is more complexity on higher layers. USB HID (mice and keyboards) is often the first you'd want but it is special in that it allows a device to describe its own packet format in a tokenised data description language. The device only has to send an additional blob when asked, but the host has to parse the contents of that blob and use the result to parse the device's packets.
And of course, every time there is complexity in a protocol and there are multiple implementations of it, there is more opportunity for them to be incompatible in very subtle ways. This phenomenon has caused for example that some gaming keyboards with N-key rollover that work perfectly on MS-Windows without any special drivers have been rejected outright by Apple or Linux hosts. (I hope these issues have been fixed now, but I'm not sure).