I feel like you could support hot-plug, discovery, and bit errors with a protocol orders of magnitude simpler than USB, something you could bitbang on an ATTiny45. (And without Neywiny's list: 'bit ordering, half-duplex, the 4 modes, chip select to first clock setup times, bits per word, "strobing" nCS between words.' Those incompatibilities are mostly just people taking shortcuts.) And, unless you're talking about USB-C PD, which isn't involved here, the power-supply question isn't really related to the software complexity; it's just a question of making the power and ground traces on the USB-A plug (and the corresponding parts of other connectors) longer than the data traces so they make contact first.
You couldn't make it quite as simple as (a given flavor of) SPI, but something close to I²C should be feasible.
I never thought about making hot pluggable SMBus peripherals. It's an interesting idea. Many motherboards even have headers broken out, and of course operating systems already have drivers for many SMBus peripheral types. LoFi USB.
We have hot pluggable I2C at home. Every HDMI port (and pretty much every DP port with a passive adapter) has I2C on the DDC pins. The port also provides 5V 50mA so your MCU doesn't need external power. Example: https://www.reddit.com/r/raspberry_pi/comments/ws1ale/i2c_on...
Perhaps there is a place for a simpler alternative. My comment was pretty tangential to this discussion about the merits of SPI vs USB vs whatever. My point is that I believe some benefit can be had by software developers in understanding how components can be integrated together using a primitive as simple minded as SPI. I used the qualification "some" again, as well. I don't offer any revolutionary insights, but if you survey how SPI is used in practice, you'll learn some things of value, even if you never use SPI yourself.
I think there's something like a dual of the uncanny valley when it comes to protocol complexity vs adoption. Really simple like UART, I2C, or SPI, and engineers will adopt it on their own. But once you start wanting to add some higher level features, engineers would just as soon reinvent their own proprietary schemes for their own specific needs (the "valley"), and the network effects go away. So to create a more popular protocol you end up with a design committee where everyone piles in their own bespoke feature requests and the thing ends up being an ugly complex standard that nobody really likes. But at least it gives it a shot at wider adoption to prime the pump of network effects. (Or maybe it's more akin to how Java beats the Lisp Curse by using the social effect of having to raise an army to do anything?)
The main reason it's near impossible to bit-bang USB is that all devices to are required to use one of a few fixed clock rates (1.5 MHz, 12 MHz and 480 MHz), unlike SPI and I²C which allow variable/dynamic clock rates.
If you simply remove this restriction, bit-banging USB would become trivial, even with all the other protocol complexity.
Though, I think USB made the right call here. The requirement to support any clock speed the device requested would add a lot of complexity to both hosts and hubs.
Only supporting a few fixed clock-rates makes certification and inter-device compatibility so much easier, which is very important for an external protocol. Supporting bit-banging just isn't that important of a feature, especially when the fixed clock rates really are that hard to implement on dedicated silicon.
USB generally needs a crystal or at least a ceramic resonator to meet its timing precision specs, though apparently Dmitry is getting by without one here. This commonly adds extra cost to USB implementations, because dedicated silicon isn't sufficient; you also need some precisely tuned silicon dioxide or similar.
In V-USB, usbdrv/.[ch] contains 1440 unique lines. The bitbanging stuff is mostly in .S *.inc, so correct me if I'm wrong, but I think this is roughly the non-timing-related complexity imposed by USB protocol stack. (This division is not perfect, because there are things in e.g. usbdrvasm.S which have nothing to do with bitbang timing, but I feel like it's a reasonable approximation.) The remaining complexity in, say, examples/hid-mouse/firmware/main.c is only a few dozen lines of code.
And that's a USB device. Implementing a USB host is at least another order of magnitude more complexity.
You definitely don't need 1000+ lines of code to implement, say, the PS/2 mouse protocol. From either side.
So, while I agree that a lot of the difficulty of bitbanging USB results from its tight timing constraints, I don't agree that what's left over is "trivial".
USB served its intended purpose extremely well, being maliciously complex is a feature. The goal first and foremost was to put the PC at the center of the future digital world, to avoid a timeline where FireWire or something like FireWire linked our devices together w/o a PC as an intermediary.
I would love a protocol you outline, but could you use SPI as the physical layer and put the rest on top?
I think, with appropriate adjustment of pin lengths (so that GND is always first to connect and last to disconnect), Apple Desktop Bus is hot-pluggable. There are even adapters for this purpose, made by hobbyists. May want to install a wee bit of software on the host, to occasionally force a rescan of the bus, but not strictly necessary.
Isn't that basically what USB is? At least if you stick to USB 1. Obviously, since that time, it's expanded to cover a wider range of capabilities. It's a half-duplex serial line, just like I2C. Unlike I2C, it's asynchronous, like a UART.
You couldn't make it quite as simple as (a given flavor of) SPI, but something close to I²C should be feasible.