My new kernel can still find the device. Looks as if the installation of the new kernel clobbered the old driver.
I edited /etc/wpa_supplicant.conf and removed the double quotes from the psk line. Then I clicked the netapplet but couldn't get the refresh to scan, so I closed that and right-clicked the netapplet. I went to Active networks and selected the wireless and it connected instantly.
After more experimenting - the quoting is not important, so leave it quoted. Connecting by Network Centre fails, changes the protocol to WEP Open, and removes the first character from the Pre-shared Key, possibly not in that order as any attempt to return the protocol to WPA-PSK will now be thrown straight back to WEP. I suspect the corruption of the stored key is the problem. Why this should be written during the connection process is unclear. One would think it only needs to be read. However, it would appear it is being read, (converted to an integer?), and written back, and although a 64-bit system can handle a 40-bit key that way, a 32-bit system loses the leading two characters of the hexadecimal version. One of these characters is replaced, presumably a failed attempt to store and replace the first two which has gone wrong! Probably an upstream bug, I would think. Presumably the author has only a 64-bit system on which to test. (Does this behaviour point in the direction of the libDrakX perl scripts?)
The problem could be in either the Wireless connection GUI (or more likely its backend) or wpa_supplicant. I suspect we need to roll back until the bug is fixed. I have tried setting update_config=0 but that makes no difference.
In the meantime, memorise the first digit of the Key. When the connection failed box appears, OK it and click configure. Set the protocol back to WPA-PSK and enter the first character at the beginning of the key. Click OK and wait a few seconds. It will now continue to try with the correct key and should eventually succeed.
Edit: Using wpa_cli to list, select and connect works well enough, but libdrakx-net is over 7 months old. Could this be one of those situations where a bug is exposed when a dependency is upgraded?