Well, it's simliar to qxl vs. qxl-vga. It's not qxl,vga={on,off} and libvirt has no problems to deal with that ...
Another more technical reason is (again) hotplug. ramfb needs an fw_cfg entry for configuration, and fw_cfg entries can't be hotplugged. So hotplugging vfio-pci with ramfb=on isn't going to fly. So we need a separate device with hotplug turned off.
Well if that's not supposed to work ever, libvirt's hotplug code could format the following FWIW: "-device vfio-pci [opts],ramfb=off"
As such, new device wouldn't be that of an issue for libvirt if vfio-pci and vfio-pci-ramfb are back to back compatible with all the device options that are available for vfio-pci (I mean in terms of using an mdev). Because in that case, what libvirt could do is to look whether we're supposed to turn on the display, if so, then we need support for this in capabilities to query and then we could prefer this new device over the "legacy" vfio-pci one. However, if we expect a case where QEMU would succeed to start with an mdev mapped to this new ramfb device but not with vfio-pci, then that's an issue.
vfio-pci and vfio-pci-ramfb are identical, except for the later having a boot display (with display=on), and vfio-pci-ramfb not being hotplugable. So, yes, all pcu/mdev devices should work with both vfio-pci variants.
But I'm still curious about the ramfb=off possibility I asked above for hotplug nonetheless.
Well, the problem is introspection. qemu can report via qmp whenever a specific device supports hotplug. A device which can both be hot-pluggable or not hot-pluggable depending on some condition is a problem here ... cheers, Gerd