One thing that helps is that the rest of meshtastic tries to be pretty agnostic on what the actual transport is at the bottom.
I initially looked at qmesh and reticulum and they both looked really cool but also still pretty ‘alpha’. I also looked a lot at disaster.radio but its implementation was super power inefficient and not really designed with off-the-shelf radios in mind.
So for our current transport: I initially used the mesh router that was part of RadioHead. Then I added flood routing and substantially lowered battery consumption (by letting the main CPU stay in light sleep). Later - for more support for more radios, I changed the phy layer to be based on RadioLib rather than RadioHead.
If someone wants to do the evaluation and effort to port our transport to use qmesh/reticulum or openthread I think that would be great. My personal queue of tasks (nearterm: more devices, multi channel support, mqtt, global messaging gateway and store in forward messaging) are more in areas that are ‘above’ the transport layer.
For the current (and nearterm - next six months?) usecases I suspect the current transport is adequate, but eventually we will want something better.