There is some overlap in the things you are doing and the experiments I did. See write-up below. I had to spent some time in getting the MQTT-SN protocol working with a MQTT broker (registering topics etc.) using the Nordic examples. Let me know if you encounter the same kind of problems.

I have OpenThread running on a few nRF52840 nodes (Nordic DK, Nordic Dongle, MakerDiary dongle).
I have a Raspberry PI with the OpenThread Border Router runing the Paho MQTT-SN -> MQTT gateway.  
This gateway is talking to another RaspBerry PI running Home-Assitant and a MQTT (Mosquitto) broker.
On the nRF52840 DK, I implemented part of the MySensors protocol. It is using the MQTT-SN protocol for communication. I am using it with a BME280 sensor. I used the Segger IDE for this (free license for nRF52840 hardware). The Nordic nRF52840 DK in combination with Segger IDE is very much needed if you want to debug your code (or repair your bricked dongle :-)).
On the Home Assistant, I installed the MySensors MQTT gateway. Actually, the whole thing is working (Temperature/Pressure/Humidity available in Home Assistant). But it is just a POC with not even alpha quality code (My C knowledge about malloc/free is a bit rusty after 15 years of Java/C#).

Absolutely, you apparently managed to do all what I planned to do in direction openThread and nRF52840.

To be honest I left that on the side and focused on taking advantage of the network in applicative level. Zigbee2mqtt has had a major impact on my projects, I just adopted it. I tend to favor ready HW over my custom one as long as the cost is reasonable.

I'll keep working on the OpenThread anyway from time to time, so if you have any openSource or github project examples, that'd be awesome, otherwise already some advises and recommendations are welcome.

I also focused on performance and ported my custom mesh dongle to the nRF52840 usb and used the usb CDC device, it was not that easy to get things running by solving race conditions and adding ring buffers where necessary.

I also feel it's fun challenge to compare a custom protocol to Thread, which is an unfair comparision, but the custom has an amazing simplicity (no joining process) on the cost of custom flashing every short id in every device.

Now I have both networks deployed in parallel see my last entry on https://hackaday.io/project/20388-home-smart-mesh/log/169353-sensors-to-services-deployment.

Did you get a boot loader compiled for this dongle? I’ve been trying to get the Nordic secure boot loader up and running without much success in buttonless mode

Hi @Tim Kerby , sorry for late reply, the notification was not clear.

Same as you, I spent some efforts on the the example of the bootloader:

"nRF5_SDK_15.0.0_a53641a\examples\dfu\secure_bootloader\pca10040_uart\armgcc"

I followed all steps but did not succeed. It is a pain to open the small usb dongle every time, so I kept it for deployed projects only and develop using another pcb that is open.

Things evolved since, and now the official nRF52840 is available with functional bootloader, so I would recommend it for new projects. I will be porting my custom RF on it. It would be great if I manage to build a bootloader with a custom transmort using my custom RF for it, but given the alternative of using pogo pin adapters, the investment of custom BL is a bit scary.

I'm currently very active on different nRF applications

https://github.com/nRFMesh/nRF52_Mesh/tree/master/applications

so let me know if you'd like to collaborate on any particular one.

That chipset looks pretty cool, a nice way to integrate sensors into small products.

In which conditions do you reach the 25 µA power consumption?

Thanks @electrobob , well 25 uA is an honest measure of the currently deployed firmware sleeping to be awaken with RTC, with the nRF52 module, BME280 and MAX44009 modules unmodified. Also not sure if the BME code can be optimised, and there is potential to do a lot better for the nRF52, as the datasheet mentions 1.9 uA with RTC and RAM retention is less than that. The tx time is neglected as hundreds of microseconds every 20 sec. But I still have to work on the full power profile, also going up to +4 dB. I'll do that with a scope and serial reistor. But let's say that power optimisation is not the priority because I'm logging continuously the battery voltage and it looks good so far, around 0.1 V drop in about a month, you can view here a snapshot I exported from my grafana : https://snapshot.raintank.io/dashboard/snapshot/KFgd0ih2HUpzdOmFNfjDbFByhm5Gp505

Indeed, both sensors should be well below 1µA each, but better check the extra components added and what is happening in the SoC. I think you should be able to keep sleep below 5µA and another 5µA for the data transmission, going for 2-3 years from a CR2032. 

Yeah 2-3 years that's a nice target usually reached with the nRF52, the CR2477 would be for a timely waking up listener or more extensive communication.

For my router nodes, there's no chance running them on batteries, as I allow the low power devices to sleep as long as they want, so the routers have to be listening full time ~ 10 mA. Low power and real time mesh is a real challenge, so now I stick with Home application where every corner is allowed a USB power supply for the surrounding low power nodes.

Since you are talking about router nodes, what is the maximum range you have?

I have two types of routers that can operate on the same mesh, one for long distances from my previous project #Home Smart Mesh  based on an STM32 and an nRF24 + PA + LNA, The metal shielded ones seen on the picture promise 2KM, I only tested them indoors and they could still send (1 msg out of 100) through x4 floors, I have no good unit for measure but e.g. 80% of messages through 2 ~ 3 walls.

The second type I stick with in this project is a much less powerful repeater (+4dB default nRF52 usb dongle), in favor of a much better design integration, inside a wall usb socket you would barely notice them. Another advantage is the RSSI only available since the nRF51 / nRF52 series, and I'd like to base the concept of this mesh on top of that, where every ~ 60 sec, every low power node sends one alive message, which acts like a trace-route, with every router appending the RSSI and tx power to the packet, the server thus can fully diagnose the mesh permanently from all redundantly received routes, also working on a webgl 3d viewer (preliminary version already shared on github) we'll see how that'll end up.

I have found some nRF51 + PA + LNA modules, I'm tempted to use them as another variation, but at the beginning I try to minimize the variations and get them better working first.