Importantly, in terms of AppArmor, these are all symlinks to a particular device. Suppose we were to add policy to the serial-port interface for this, it would be simply:
this rule alone is harmless enough because it only allows listing the directory where an application could try to open one of the files. Because that directory contains only symlinks, AppArmor resolves them to what the symlink is pointing at, eg, /dev/ttyUSB1. Considering that for device assignment like this the device cgroup is used, a snap that was assigned to /dev/ttyUSB1 would only be able to open /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DM007FNY-if00-port0 and not /dev/serial/bu-id/usb-FTDI_FT230X_Basic_UART_DM007X1O-if00-port0.
The problem comes when we use product/vendor in the gadget, because for these FTDI devices those are (apparently) the same and so snapd adds udev rules (for tagging the device to be used in the device cgroup) for both to a connected snap, thus breaking the 1 to 1 mapping that we want (and @niemeyer is discussing). I should note that this is already broken today since there is no way to differentiate between two identical product/vendor devices.
It sounds like this forum topic (topic subject notwithstanding) is really about how to differentiate between two identical product/vendor devices. In this specific example, I don't think that the DM007FNY vs DM007X1O serial numbers are interesting in the gadget yaml (ie, the 'usb-serial' idea), since others have said every FTDI device has a different serial number and exposing that in the gadget yaml only helps the one person who has the devices with the serial numbers that match what is in the gadget. IME, that means 'usb-serial' is useless as a fixed list in the gadget yaml (at least for this specific FTDI scenario).
If the FTDI devices are hardwired on the device, then the gadget should instead use the alternative
path: /dev/ttyUSB1 declaration in the gadget yaml and skip product/vendor. If the FTDI are not hard-wired, I think we must consider them as hot-pluggable. For the hot-pluggable situation, it is clear that when two devices are connected with identical product/vendor, snapd will (likely) have to look at other info to disambiguate them (perhaps the serial number is a part of that) and somehow remember that info and utilize it when performing interface connections and across hotplug/unplug, but this is still TBD (to be designed).