The UK "hack" for the bluetooth was quite clever from what I saw - in essence they implemented the "background discovery of an iPhone" feature.
One concern I do have with this approach is that the decentralised system inherently can only model the "risk-to" an individual from an epidemiological perspective. It can't model the "risk-from" side of things. To avoid Sybil type attacks, you need to use centrally issued (and thus verifiable) test results to notify others.
Unless tests are administered very promptly, with results immediately available, it seems difficult to make this work in the decentralised approach - with a mean and median "time to symptoms" of around 5.1 days [1], and someone at their most infectious for the 1 to 2 days prior to experiencing symptoms, it seems decentralised apps will struggle.
If A is infected on day 0, then on day 3 they may infect B and C. On day 5, A experiences symptoms, goes online, and requests a test, saying they have symptoms. They realistically would get a test the following day. and the result the day after that. That would be day 7, and at that point, B and C might be notified by the app. The issue is that B and C are now on day 4 of their own infections, the second day of their most infectious period, walking around unaware. They find out the day before they would themselves (on average) experience symptoms.
Clearly the virus is not as deterministic in behaviour as in this simple model, but the above seems to suggest to me that to get any real value out of this (i.e. preventing the next generation of infection), you need to either be able to respond to symptoms reports, or significantly expedite the testing process. In the above situation, a same-day test-and-result would enable B and C to be notified on day 2 or early on day 3 of their own infection, potentially having some real impact. But to achieve this, the latency of testing would need to drop hugely.
[1] https://hub.jhu.edu/2020/03/09/coronavirus-incubation-period...