Some more testing, trying to find the source of the problem:
I powered the radio from a battery, instead of my bench supply, just to make sure there was no weird ground loop or other noise injection going on. No difference in operation.
Side note: I also discovered something to be careful of (Someone else may well have discovered and mentioned this elsewhere): If I leave the programming cable attached to the radio but do NOT have it plugged into a live USB port, when I turn on the radio, it starts transmitting and stays key-down. If I start with it plugged in and unplug it, nothing happens but when I plug it back into the USB port, the radio briefly transmits.
I probably shouldn't even share this next section -- I'm afraid that it will muddy the water and that someone reading this thread will latch onto in and it will distract the conversation away from the real issue, which is its behavior on my Linux box -- but, in the interest of completeness...
I tried the cable & radio on a different machine, running WinXP.
I installed the Prolific driver from the CD that came with the cable. Installation went fine.
Hyperterm echoed chars, but I saw nothing appear when I pushed the button on the radio. I also confirmed that I had the right port by unplugging the cable and observing that the echo no longer worked.
I installed USBPcap and WireShark. The format of the dump is a bit different than in Linux (with more "CONTROL" stuff shown). WireShark showed activity when button pushed, but I didn't see the expected data in there. It appears that instead of sending the "AH008$.$" string, it was sending a NUL char for each one of the 8 chars. It looked like the PC replied back with a 0x06 as it did on Linux, then a few more 0x00 chars came from the radio before the connection was shut down.
CHIRP (20150513) returned this error as soon as I pushed the button: Error reading echo (Bad cable?)
I installed a trial version of G4HFQ's commercial software to see if it would give any clues. It gave me this when I pushed the button: FTB8900 The rig identifier expected was X'414830303824'
but the identifier actually received was X'000000000000'
We cannot continue with the read process. This agrees with what I saw in WireShark.
Thus, under Windows (on different PC hardware), though the PC is clearly communicating with the radio, the result is different (and inferior, with less correct info exchanged) to what I was getting on my Linux machine. Why the difference?
Here's a wild guess, without thinking it through much: what about an analog problem, like a signal voltage that's lower than it should be -- right at the threshold of proper operation -- and minor power differences between the two machines might make a difference of all zeros vs. correct data in some circumstances but not others? I don't have a digital storage scope, so even if I opened things up so I could get a probe pair in there, I'd get only limited info about that.
(After this test, I moved the cable back to the Linux box, and verified that it still behaved as before.)