Are you certain?
I've only had 15 years of development experience in the Windows kernel and 4 years with the Arduino, but I am reasonably certain that:
1 - The 16U2 chip on your Arduino is correctly enumerating and identifying itself as a USB/Serial device to the Windows Kernel.
2 - The Windows Kernel is recognizing the USB PnP event and instantiating an instance of a USB/Serial class driver - (COM23 according to your screen-shot)
3 - The 16U2 chipo on your Arduino Uno is transmitting the correct USB Vendor and Product IDs for an Arduino Uno to your computer.
4 - The Windows Kernel recognizes the USB vendor and product IDs transmitted by your UNO and loads the appropriate UNO-specific .inf., thus identifying the device to the Device Manager as an "Arduino Uno"
5 - At this point the Arduino UNO becomes a passive serial devices waiting for CTS to be asserted when the COM port is opened.
It's the Arduino IDE that claims this error, and your assessment of the situation is a bit glib.
Keep in mind that the Arduino IDE is executing 100% in Windows, not on the Arduino. If by glib you mean unsubstantiated, I'm sorry for not providing a more detailed explanation.
Based on the Device Manager screenshots provided, the Arduino Uno is available and ready for communication (see above). And based on the errors reported by the Arduino IDE, the IDE is unable open the COM port. From a kernel-mode driver perspective, this means that the IRP_MJ_CREATE packet to the USB/Serial class driver was returned with a status of STATUS_ACCESS_DENIED. This usually means that the device is already opened by another process, but could also be returned in the event that the requesting process does not have access rights to the device.
Assuming that the error is being accurately reported by the IDE, the COM port is not opened and no actual download has been attempted.
I will grant that it is possible that the Arduino IDE is reporting the error incorrectly. (Arduino 1.0.5 is rather new and may have some bugs I am not aware of.) IRPTracker from OSR could be used to verify this if you are comfortable with kernel-level debugging tools. (You should be able to see the IRP_MJ_CREATE transaction as well as any follow-on IRP traffic ). For a QnD diagnostic: is there any LED activity on the Uno when you attempt to download?