As @pjc50 says in a comment, Xon/Xoff is flow control, not block-control.
If a receive buffer is full, the device with that buffer sends "Xoff" to the other device to make it stop talking for a while. So your putty will send "Xon" when initiating, then only send "Xoff" when the port's buffer is full, after which it sends "Xon" again when there's room for new data. It's likely your Atmel is much slower in handling data than your PC, so as an effect it is unlikely the PC will ever decide to send Xon/Xoff to the Atmel on its own.
That said, I do sometimes write logger firmware that "pumps" out data at 1MBit+ and then windows specifically will start whimpering. I have never tried whether it then sends Xon/Xoff, as I often then migrate to direct USB communication, becuase I need the stream, not some "chopped" simile. In Linux, however, I have not had any buffer issues up to 5Mbit on serial interfaces.
EDIT:
As a side note: I have seen many worse things in the world than using Xon/Xoff for handshaking rather than flow control, so comparatively you wouldn't be that bad. But semantically you should use other special characters for block-handshaking procedures. Such as SOH, STX, ETX, EOT, ENQ, ACK, NAK, SO, SI, CAN, EM.
You are also allowed in Ascii to use DC1 through DC4 for whatever you like.
See the Ascii Control Table for more fun names and numbers.
If you already have an ADC, you will need something to read your ADC!
You mention a serial to USB cable in your OP. Let's assume that the task is modest enough for all the information to fit into a standard serial data stream.
Without wishing to plug any particular manufacturer, I will tell you what I do for the simplest possible solution of hooking something dumb and digital to a PC.
Use an Arduino (Uno is the easiest to start with) which plugs into the PC USB port directly. The USB allows you to program it. It also allows the PC to communicate with it using standard serial protocols, and is fast enough to talk serial and then do some extra work. The standard Arduino support software on the PC contains a monitor to allow you to talk with it, for testing purposes. You can then use any programming language running on the PC (Python with the 'serial' library is my choice, but anything else you're comfortable with will do, and if you're not yet comfortable with anything else, then Python is my recommendation for what to learn) to talk with the serial port. You can also pipe files to/from the operating system.
Write a program on the Arduino, in C, to read the ADC, format the data, and send the data to the PC. Use parallel, SPI, i2c, many standard protocols have libraries to simplify the task.
You can get other Arduino boards that have a serial interface, and use a USB to serial converter or cable for interface. Although the Uno plugs in directly, it does use serial under the hood, so they are more equivalent than it appears at first glance.
I seem to have used the word 'standard' a lot in this answer. That's because you won't really have to invent anything to do what you want, just hook up standard components and protocols. The tricky bit is making sure you understand what each has been designed to achieve, and then using them that way. 'Ride the horse in the direction it's going'. There's nothing more frustrating than trying to use a tool or component or library to do something it's not been designed to do.
Of course if you are already versed in PIC, then use that instead of Arduino. But I guess if you already use PIC, you wouldn't be asking the question.
Best Answer
If you set your protocol up so the cars only respond when queries by the controller, then you can just tie (at the logical level, at least) everyone together.
The trick is whether you have real RS-232 (with 1 = -6 to -12 V, and 0 = 6 to 12 V) or just a standard logic line (1 = VCC, 0 = GND). Either the data sheet or a scope should answer this.
If it's standard logic, it could be really easy. If your sensors can control their output drivers, then program them to not drive the output unless a message is going out. If you have to leave the output driver on all the time, have it drive a transistor or two to make an "open-collector" configuration, connect all the sensors' collectors together, and pull up the connected line to VCC and hook it to your main controller's RX pin. This works because the RS-232 protocol idles at a logic 1 state. If RS-232 signal levels are used, then you have to change the transistor configuration a bit, but it'll still be open-collector at heart.
The main controller simply asks each sensor for its data in sequence. Each sensor responds when queried. That way you don't have more than one driving the RX line at a time, which is the main goal.
Now if you can't get your sensors to speak only when spoken to... then your problem got a lot hard. So much that the simple answer is to give each sensor its own serial port, maybe using 8-pin controllers as sensor managers, which can then be hooked up on a cooperative serial bus. Other techniques, such as collision detection with message retransmission (like 10base-T Ethernet did), are much more complex.