UNIBUS, S100, ISA, AppleII expansion slots, etc etc etc.
Since the very beginning, I've considered that omission to be USB's great failing. There is no reason, given the technology of the time, that a driver standard built around a platform-neutral byte code could not have been done. The byte could could have been transpiled to any arch/os at driver init time, or on first USB device mount event, or some such. Glaringly missed opportunity, but nobody asked me.
The PC had a similar feature: https://en.wikipedia.org/wiki/Option_ROM
https://en.wikipedia.org/wiki/Open_Firmware
Open Firmware Forth Code may be compiled into FCode, a bytecode which is independent of computer architecture details such as the instruction set and memory hierarchy. A PCI card may include a program, compiled to FCode, which runs on any Open Firmware system. In this way, it can provide platform-independent boot-time diagnostics, configuration code, and device drivers. FCode is also very compact, so that a disk driver may require only one or two kilobytes. Therefore, many of the same I/O cards can be used on Sun systems and Macintoshes that used Open Firmware. FCode implements ANS Forth and a subset of the Open Firmware library.
The host adapter ROM contained a driver for the specific hardware on that card, written in a way that did not make any assumptions about the operating system. (Actually, there were two drivers in the ROM. A 16-bit driver for DOS and Windows 3.x and a 32-bit driver for the others). I'll call the drivers from ROM the "hardware drivers".
The generic driver would find the ROM. The ROM had a header that contained information about the hardware driver. That included pointers to various entry points in the hardware driver, including an init routine. The generic driver would call the init routine, and one of the things it gave the init routine was a table of entry points in the generic driver that the hardware driver could use to do things like allocate and free memory, register interrupt handlers, set up DMA operations, and things like that.
My recollection is that the 16-bit hardware drivers were position-independent code that could be run out of the ROM directly, or copied to RAM where it might run faster. The 32-bit code was not position independent, so the generic driver had to copy it to memory and the fix it up, which it could do because the 32-bit driver in ROM was essentially the .o output of the C compiler used to build it so had everything needed in order to move it around.
Once the hardware driver was initialized and running, the interface between it and the generic driver for actually doing SCSI commands was based on a draft version of the SCSI CAM specification. We [1] were on the CAM committee, and proposed including our ROM-based hardware driver approach as part of the standard, but most other committee members didn't think being able to swap host adapters without having to change OS drivers was useful enough.
[1] "We" == the consulting company that designed and implemented the aforementioned stuff for NCR. I was the lead architect and lead programmer for the project.
> During the design stage, Steve Jobs argued that the Apple II should have two expansion slots, while Wozniak wanted six. After a heated argument, during which Wozniak had threatened for Jobs to 'go get himself another computer', they decided to go with eight slots. The Apple II became one of the first highly successful mass-produced personal computers.
"Sorry, can't use a modem right now, I have both a floppy drive and a printer plugged in."
Given that this was the result when Jobs didn't have Woz vetoing him, i doubt it.
The guy was obsessed with looks and "experience". To him, a computer was to be a magical black box that people powered on and powered off. To open up the case and poke around inside was "dirty".