New UNO goes on different COM

Hmmm that's interesting.

For as long as I can remember my one and only Uno attaches to COM10. The other day I bought another one, and without the original connected, the new one hooked on to COM15.

Is that just happenstance or is there some internal wizardry like a serial number so the IDE thought "aha, he'll want both hooked up one day so we'll allow for that and use a different port"?

(Just thinking about this at work; when I get home I'll hook them both up and see if they're still on 10 and 15. If so I should be able to have them displaying output independently on the IDE monitor and say PuTTY?)

I totally remember that used to happen to me too. I have 4 Arduinos Uno R3s and used to have projects on breadboards centered around them and they used to always grab different ports. Haven't used them in a while. I gave up on breadboards and also on the physical Arduino itself. Now I still use the Arduino development environment but with a AVRISP mkII programmer and standalone chips and solder them down to a protoboard.

(I assume you are using Windows.)

A kernel driver (probably usbser.sys) makes the decision / assignment based on a serial number from the USB device and some registry settings.

The IDE has no say-so.

The assigned port can be overridden.

If so I should be able to have them displaying output independently on the IDE monitor and say PuTTY?

Or two instances of the IDE.

Or that... and a Trinket on yet another

You will notice the different approach Windoze has to USB devices.

You connect a flash drive; it says "Ah! New Hardware, go make a cup of coffee while I find a driver", then it tells you (if you are lucky) it has found a driver, tells you it is installing the driver, then the device, then tells you it has successfully installed the device and you may use it.

Plug in another flash drive of the same model and it goes through the process again, possibly faster.

Plug in another mouse identical to the first, and the same process.

Plug it in a different port, and the same process, In fact there is - at least in some versions - a limit on the size of the table it keeps to register these device/ port associations and if that table is filled, well ...

Linux - at least recent versions - has a different approach. You plug in a USB device. The disk activity light goes on briefly, then nothing happens unless it is a mass storage device, in which case a file browser window opens on the new mount.

If you happen to have a file browser window open on /dev organised to show the latest first, a device will show up. It basically does not care about the identity of the device, only how to interface with it.

The big blunder is that the IDE only enumerates when it is started up.

Paul__B:
The big blunder is that the IDE only enumerates when it is started up.

Hm? It seems to update the list of available ports every time you click the tools menu for me (and if there's something funky going on with a serial port, the IDE will take 30+ seconds to open the tools menu)

Each Atmel 16U2 has a unique 10 byte serial number located in the signature row. The LUFA library used by the 16U2 Serial firmware uses this to identify a unique device ID to the Windows USB enumerator. That is why each Uno or Mega2560 is assigned a new COM port for each unique board.

For convenience I usually just re-assign the COM port back to the same number for Uno type boards.(You can change it from Device Manager, Properties, Port Settings, Advanced, COM port number setting)