Thanks @Jeff-UK for the explanation about dev nonce, sorry i see that had been mentioned elsewhere already. I’ve started a test with a node without forced re-joins, maybe that will already solve the periodic hangs i am seeing when the nodes were re-joining.
However, i’m still hoping to get some practical advice on how to make an LMIC node run robustly, and there is little i can find in the forum. Is it because the LMIC minimal example takes care of everything, should run perfectly forever, and any mishaps i experience are due to my hardware?
Regarding your suggestion “A watchdog function may well be engineeered to monitor node and signal behaviour and under specific conditions or concerns may then decide to trigger a rejoin or even a node re-boot with associated rejoin”, what i’m trying to find out is if LMIC implements this reliably, that’s why i’ve posted it in this category 
I read about EV_LINK_DEAD, which seems like an indication that something is wrong, and could be a good candidate to trigger a node reboot with re-join, but LMIC’s own solution seems to keep trying for another 720 (=816-96) uplinks. At an interval of 10 minutes, that could take 5 days. My question is, are any professional developers using LMIC relying on this mechanism, or do you implement it differently?
Are the 2 other features i mention (back off when join_failed, timeout of txcomplete) good ideas or are there better ways to do this with LMIC?
I also found another suggestion to include a downlink command to reboot the node, forcing a re-join, is it worth adding this?
Thanks for any practical advice.