You get flakey Bluetooth when the two implementations on the two devices differ significantly, or when it is poorly implemented.
... Which is made clearer by the fact that the Bluetooth specification is:
+ Enormous. Even just the core spec, that doesn't include much of what the consumer is interested in, is around 3000 pages long. That's not a typo. 3000 pages to tell you how to make two devices do a handshake. Add in the things that make our devices actually work... And you're asking the software to match what has been written and defined across closer to 5000 pages. Nothing is going to perfectly match between implementations.
+ Badly defined. The original working group that made Bluetooth left behind so much because they couldn't agree on it that it has more "Undefined Behaviour" footguns than C ever did.
One example of some spec text that I've seen argued differently between implementations:
> There is no requirement for the application to insert additional
framing information into the data, although it may do so if this is required
That's before we get to the actual real world problems that Bluetooth has to face and overcome, like being in the 2.4Ghz range and being a frequency hopper.
Part of the big thing that's missing in those 3000 pages is limitations. Once a bluetooth connection exists there's really nothing preventing the device from using any of the profiles available, other than limits placed by the item connecting. Connect a bluetooth audio device? It can just become a internet route for you, or become something that accesses contacts, or any of the swath of different profiles available.
Good reply...but the real question is why has nobody stepped up to replace it? Close quarter communication is only becoming more prevalent, why do we live with a broken standard?
The LTE Bluetooth standard actually does make large inroads towards removing a lot of the less clear parts of the standards, and reducing the size of the specification. It is still far from perfect, but attempts are being made by the industry to clean things up.
WiFi Direct (which is also somewhat horrible, but somewhat less), is also a competitor in this area. It hasn't seen a lot of adoption, but there are a few things that use it.
Apple's AirDrop is also a proprietary protocol that can handle a lot of this peering stuff, atop WiFi, and they seem pretty committed to keeping it around for all their stuff for the foreseeable future.
Zigbee is more of a competitor for Bluetooth Low Energy, which is quite a bit more modern, sane and reliable than Bluetooth Classic.
It never really had much of a chance though because BLE support was sort of added to phones for free as part of Bluetooth. With Zigbee (or ANT or Thread) you'd have to add a new chip, which phone manufacturers aren't going to bother with for a tiny market (though I think there are a very small number of phones with ANT support).
... Which is made clearer by the fact that the Bluetooth specification is:
+ Enormous. Even just the core spec, that doesn't include much of what the consumer is interested in, is around 3000 pages long. That's not a typo. 3000 pages to tell you how to make two devices do a handshake. Add in the things that make our devices actually work... And you're asking the software to match what has been written and defined across closer to 5000 pages. Nothing is going to perfectly match between implementations.
+ Badly defined. The original working group that made Bluetooth left behind so much because they couldn't agree on it that it has more "Undefined Behaviour" footguns than C ever did.
One example of some spec text that I've seen argued differently between implementations:
> There is no requirement for the application to insert additional framing information into the data, although it may do so if this is required
That's before we get to the actual real world problems that Bluetooth has to face and overcome, like being in the 2.4Ghz range and being a frequency hopper.