I think there is a confusion somewhere here. You cannot say "slave DB9 device" because even though DB9 is used for countless protocols (CAN, USART etc.) none of them has anything to do with the meaning of USB slave device.
Unless, of course, this DB9 is connected internally to another Serial-to-USB converter inside that leads to actual USB slave further down the line. But since hiding USB slave in a box separated from the world by serial interface has very little sense I would assume it is not the case here.
So, you basically have some unknown (to me) device with some TTL based serial protocol on the DB9 side. By connecting RS232-to-USB cable to it you do NOT magically make it a slave device. Or, more precisely, you make it into "vendor class" USB slave with FTDI (or whatever chip is inside that cable) interface descriptor.
On the other side you have device with USB connector internally attached to FT232R chip and further to MCU with serial interface. This tells me that Slave 1 is not a true USB slave either. FT232R chips are used as a transport layer between serial interface of the device and virtual serial port on the host computer.
Which basically means you have another serial device (neither host nor slave) on this side as well. And if you have an access to its firmware you can program whatever serial protocol the DB9 device supports. This is a good thing.
The bad thing, is that FT232R chip requires host in the middle, no workaround here. So, you basically have four options:
Hardware + Software option: Make your own adapter with USB host based on USB-capable MCU. Your software will have to work as FTDI driver too. This is most complex approach but it should make it possible to not make any changes in Slave 1 firmware.
Hardware + Firmware option: Make your own adapter using Vinculum chip from FTDI. Load it with pre-programmed UART-to-FT232 host bridge software image. It is possible that someone already making these adapters or cables commercially, so surf the web for it. Modify firmware on Slave 1 to communicate to Slave 2 as if they are connected directly by UART. This is most portable approach, basically your own RS232-to-USB cable.
UPDATE: actually, FTDI makes development board practically ready for this application.
Software option: Connect both devices to PC, Slave 1 directly, Slave 2 via regular RS232-to-USB cable. You will get two COM ports on the computer. From here you can write "controller" program to communicate with both devices via those COM ports.
Software + Firmware option: Connect both devices to PC as above. Bridge two COM ports using any available software, like virtual serial port driver by Eltima. Modify firmware on Slave 1 (exactly like in option 2 above).