I have to say that I _really_ doubt the devices are BLE-only, mainly because of bandwidth constraints. If they plan to still keep the "applications-uploaded-on-demand" charade, I'm quite sure they still use normal Bluetooth for that; otherwise the delay to use a program would more than annoying.
If you have any more confirmation about that than CEO-speak it would be interesting.

In fact bandwidth is the main reason that so far no smartwatch has actually been "BLE-only". I only know of some editions of the Metawatch, and some fitness bands.

And I used to connect the BLE Metawatch happily with my Nokia N9, which had a kernel that was even older kernel than the Jolla
On the N9, the kernel had a limitation regarding BLE Random addresses, but that's no longer present on the Jolla, and random _static_ addresses work fine (right now my Jolla is connected to a Garmin Fenix without problem).



If it turns out that the newer Pebbles are BLE only, or that some functionality is only accessible via BLE, as mentioned, you might want to use a "mostly user-space" BLE stack, such as Gato or backport Qt Bluetooth 5.4 (which was partially based in Gato).

With both approaches you have the same limitations as described in https://together.jolla.com/question/...th-le-support/ .
To summarize:
* Scanning for devices is difficult because it requires root access. Maybe a small setuid binary or something like that to trigger the scan.
* No "peripheral" role (i.e. Jolla must connect to the watch, not viceversa).
* Pairing is possible, but not safe: LTKs are _not_ stored by Bluez, so MITM attacks are possible. However, BT4.0 has confirmed security holes, so MITM attacks are technically possible even if LTKs were stored.

(On the Jolla, Bluez4 will not scan for LE devices because it thinks it's not on a BLE device. I've managed to confuse it enough so that it actually scans for BLE devices, but it's ugly. )

Please note that there's not much Jolla can do about this since we're about the only platform (other than ChromeOS) where there's any interest in using Bluez4/5 stack with BLE+GATT. Updating the kernel will not help anything, unless they update it to extremely recent version alongside a extremely recent version of Bluez (which has upstreamed the ChromeOS GATT patches), and then fix QtBluetooth, and then recertify the device, and then...

In any case I suggest waiting to see if the newer Pebbles are BLE, and if they are, "how much" BLE they are before any move.