Maybe not.
Just to summarize then where I think this could land:
The capability folders (plate_reading, imaging, spectrophotometry, liquid_handling, etc.) stay as they are and continue to hold the universal frontends.
The concrete device classes move to a separate devices/ (or /machines) folder, which can be organized internally by vendor. The vendor name wouldn’t need to be part of the public import: devices/__init__.py can re-export everything so users simply write from pylabrobot.devices import Cytation5. That also solves the BioTek → Agilent issue: a folder rename and a small change in devicdes/__init__.py, without breaking user-facing imports.
One personal note, PLR’s hardware-agnostic architecture feels like more than just a software design choice. Being able to swap a CLARIOstar for a SpectraMax without rewriting protocols is the point. So while vendor folders make sense as internal organization, keeping them invisible to users feels important. That’s probably a personal preference more than a blocking concern, and the __init__.pypattern addresses it well enough.
My concern was mainly that moving to vendor organization might replace the capability folders as the primary entry point, but I don’t think that’s actually possible given that universal frontends need a vendor-neutral home by definition.