I was working on a project related to Bluetooth and the operating system requirement was Microsoft Windows XP. The service was to connect with the devices built-in Bluetooth Radio, find a specific headset and pair a device at the will of the user. Think of it as speaking "Connect to my headset that I have here" and it would just work. Simple, and quick - that was the goal.
Technical perspective
It appeared that we could connect the headset, find the audio service and then... The code would sit, waiting for the pairing to complete, and would eventually fail. The poorly implemented WIDCOMM tools could see it, pair with it, and Windows could play audio through it if the WIDCOMM tools did the pairing - but something was preventing our code, using the API calls that we saw WIDCOMM use, to fail during pairing. They were doing something else that we couldn't readily discover. (The other problem was lack of any usable error information...)
I found that there was an update to the WIDCOMM Bluetooth stack that was installed in the system, and downloaded it, installed it and... Now another problem - the Audio service profile for the headset was suddenly not available. I could pair the device through code or Windows manually and send and receive text to it as a serial port, but not either play nor receive audio over the device.
I found that even if I installed the old Bluetooth stack, the audio service had somehow been removed from the system during the install. I put back a backup copy and was left with the error issue and now a new issue. The project was refocused to make this a 'Nice to Have', but I was still bummed. WIDCOMM didn't use the Microsoft stack, and Microsoft didn't know how to use the WIDCOMM Audio driver component of their stack.
From a customer's perspective
This is the type of thing that drives consumers crazy, never mind the technically minded. When we ignore the technical issues of stack versions and manufacturers, the bottom line is that the hardware says it supports Bluetooth, but the technology is deeper than just a simple "yes/no" in terms of full support. Technical people may know there are different communications types, from network to Audio, to Serial Port, PIM transfer, etc. - but to the client, they just want to grab a laptop or desktop with Bluetooth, grab a Bluetooth headset and plug and play.
Other things work this way, too. CD-R at the beginning was a problem, where you could only play your CD-R's on some CD players. DVD is now that same way too. Early DVD drives may not play DVD+R disks, etc. I am also finding that differing Windows Mobile 5 devices having similar problems, such as a Treo trying to use ActiveSync over Bluetooth with Vista, or sending/receiving files to an HP IPAQ 6900 from the Treo.
I wonder sometimes if technology is moving to fast for the companies producing it, because it happens all over and continues to happen. One day, will I get the chance to blog about the problem being fixed? I won't hold my breath.