quoted

The second way is to have a number of #ifdef and complex
Kconfig dependencies for the driver to only register the
device_driver objects for the buses that are enabled. This
is also doable, but everyone gets the logic wrong the first time.

Hm, I understand now why you'd prefer to have a single bus. Can't we
solve this problem with a module_i3c_i2c_driver() macro that would hide
all this complexity from I2C/I3C drivers?

Do you know of devices speaking both i3c and i2c as of today?

I think I3C/I2C is a bit different than I2C/SPI. For the latter, it
might happen that you have only this or that bus on the board, so it
makes sense to support both. But if you have I3C, you can simply attach
the I2C device onto it. I guess you would only implement I3C in the
device if you explicitly need its feature set. And then, a I2C fallback
doesn't make much sense? Or am I missing something?

OK, now I know that those I3C+I2C devices will exist, even if only for
Murphy's law. However, my assumptions would be that those devices are
not common and so we could live with the core plus bus_drivers
seperation we have for SPI/I2C already (although I would love a common
regmap-based I2C/SPI abstraction).