I recently bought a new IC-9100 that comes with an USB interface. Through this interface 2 serial ports (based on Silicon Labs UART/USB bridge) and the audio codes are emulated to the computer – the same like on an IC-7200 or IC-7600.
I’m using a Mac and installed the latest drivers for the USB/UART bridge. When switching on/connecting the transceiver to the Mac two new ttys (e.g. /dev/tty.SLAB_USBtoUART and /dev/tty.SLAB_USBtoUART2) are created.
When I set up those parameters for example in fldigi everything works fine (PTT, CI-V, etc.). When I now switch off and on the transceiver or remove and plug the USB, everytime I do this a new /dev/tty.SLAB_USBtoUART[n] is created and the /dev/tty.SLAB_USBtoUART (without a number) is created too. The problem is now not only the always incrementing device name – the major issue is that this two devices always randomly swap; that means that one time the one without the number at the end is for CI-V operation and the other time the one with the number is for CI-V operation; so everytime I need to re-setup all rig specific values in fldigi again.
I debugged now for a few days and found out that the USB VendorID and ProductID is for both UART/USB converters the same – the only difference is the USB serial number. For the one device it is „IC-9100 0xxxxxxx A“ and for the other one „IC-9100 0xxxxxxx B“. As I understand they are both together with the audio codec on the same in the transceiver integrated USB hub. Every try to make the MacOS consider this USB serial number (e.g. a special entry in the Infp.plist of the kernel extention) failed.

Update 13.03.2011: I managed it now to have only one device when (re-)connecting the transceiver. In the transceiver are two Silabs USB-UART bridges; there is a tool from Silabs for OEMs to flash the internal EEPROM with an own Vendor-/ProductID. With this tool you can even edit all other settings like the max. current, the serialnumber, etc.
I used this tool and modified the ProductID just a little at the end with the result that the unused 2nd interface will not be determined by the driver. So now I only have exactly one (and always the same)  /dev/tty.SLAB_USBtoUART. It is not the „soft“ way solving this problem and it is very dangerous due to the fact that you might destroy your EEPROM or even the content and might never be able anymore to access it. But for me it worked; and: no risk – no fun.