bluetooth: doc: Describe future API direction changes.

TBR: scheib@chromium.org
Change-Id: I467adbf5ff9304eea15f8c597565ce84384fbc18
Reviewed-on: https://chromium-review.googlesource.com/810058Reviewed-by: Vincent Scheib <scheib@chromium.org>
Commit-Queue: Vincent Scheib <scheib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521932}

device/bluetooth/README.md

@@ -35,13 +35,28 @@ features and the Chrome Apps APIs:
 * [chrome.bluetoothLowEnergy](https://developer.chrome.com/apps/bluetoothLowEnergy)
 * [chrome.bluetoothSocket](https://developer.chrome.com/apps/bluetoothSocket)
 
-Active development in 2015 & 2016 is focused on enabling GATT features for:
+Active development in 2015 & 2016 focused on enabling GATT features for:
 
 * [Web Bluetooth](https://crbug.com/419413)
 * Peripheral mode for Chrome OS.
 
-Known future work is tracked in the
-[Refactoring meta issue](https://crbug.com/580406).
+## Future Work
+
+The API and implementation have many known issues.
+
+The initial API was heavily influenced by BlueZ.  Low Energy GATT APIs are not
+consistent across platforms.  Some of the high level abstractions built into
+`device/bluetooth` are difficult for clients.  Several TODOs exist in the C++
+header files, e.g. `BluetoothAdapter::Observer`.
+
+Primarily, the API should be split into fundamental Bluetooth concepts and
+seperate, optional, high level utility classes.
+
+E.g. receiving advertising packets should be routed directly to clients allowing
+contents of the individual packet to be inspected.  Caching of known devices
+should not exist in the fundamental API, but be offered as utility classes.
+
+See also the [Refactoring meta issue](https://crbug.com/580406).
 
 
 ## Android