I can certainly understand those frustrations too. From my past experiences of community management, one of the hardest things to do is be able to effectively communicate to the community at large. Of those having problems, everyone is going to be experiencing something somewhat different. Quite a few will fit a specific issue, but there will be those with outliers. Still more, there can be instances where two community members may be experiencing the same issue, but exhibit different symptoms because of variables (such as using Android vs iOS).
We have had some discussions on what we think would be best to communicate to the community. Our current methodology is updating our pinned topic at the top of the community pages here. Looking it over, this topic is reasonably up to date with our latest discoveries and developments. For instance, the reliability issues you had concern with around the Xenon nodes on your mesh gateway–we believe the major factor behind this was actually a bug with OpenThread (You can find this under Issue 4 on Device Issues on our topic).
If you think it would help, in addition to updating the topic–it would be beneficial for us to make a post each time we change to the pinned topic, I can certainly relay that back during our next meeting.
In terms of your concern about not knowing what the issue is behind mobile device setup and what’s causing it–to be completely honest, we’re still not 100% confident either. We have some theories, and actively investigate them as they come up–so much so, that I’ve heard the proposed cause radically shift from one daily meeting to the next. When it is changing so wildly, it’s hard for us to communicate it when we aren’t even able to pin down anything internally.
To try and give you a snapshot, my current understanding of the BLE setup flow is primarily that iOS seems to be generally more reliable at this point. But I can’t guarantee that iOS will work without issue–which is why we want to be reserved on how we communicate this. I think it would be even more frustrating for our community at large to be told that any iOS device will do–and after they go out of their way to get one–it, too, doesn’t work for them. For your specific circumstances, I would certainly recommend you try an iOS device if one is easily accessible, but I don’t want you to go out of your way for it and expect it to work.
With Android, we have had theories of it being an Android manufacturer model, an Android Version, and even a BT radio manufacturer housed within certain Android phone models. It tends to change relatively often though, based on community feedback.
For instance, we had a day where we had theorized the issue to be around Android 7 on a certain subset of manufacturer models. Not even an hour after the meeting, I had handled a customer ticket who tested his setup with 3 different Android phones–a Samsung series, an LG Series, and an Huawei series. Each one had a different version of Android on it (6,7, or 8).It’s feedback like that that puts us back to the drawing board and sometimes makes us hesitant to communicate that out when it would get dialed back so fast or become seemingly irrelevant.
The goal isn’t to avoid communication or hide anything–but we also don’t want to give false positives or also steer the community in the wrong direction with potential causes.The feedback is immensely valuable from our community, and we want to make sure we are driving it in the right direction so we don’t allocate our community’s time and resources on something we aren’t confident in.
With that said, this is also in part why we took our time with rc26 and want to ensure a level of reliability so that our community can try it and engage with us, to figure out what still needs work and where we’re making progress.
Personally, I’m actually pretty excited for our rc26 release. 
If you’re able to get it setup (perhaps with an iOS device, if one is easily accessible for you and you’re up for giving it a go), I would love to hear your feedback!