That is in part due to perspective.
The thing about an ecosystem is it tends to effectively say “if you want to use this technology, your program needs to look like this, target this processor, use these tools…”
In contrast a professional developer is often in a position of “if you want to sell your technology to us, it needs to fit into this software philosophy and methodology, be free of forbidden anti-patterns x, y, and z, be compatible with tool drivers that want to do…”
Ecosystems make it easy to start projects, but they often make it very hard to finish them, or wrangle a project into the expectations of the organization commissioning it. What I’ve found is that when I’ve written production-destined code within a target-dictated ecosystem for the initial gain, months later I’ve regretted it (and that goes for mBed and even iOS storyboards as much as Arduino… and of course all of the old MCU vendor DOS and windows IDEs). Conversely, whenever I’ve invested the effort up front to set up the needed foundations to make an embedded project follow the same rules as expected of the organization’s other software projects, that’s paid off as the project moved along.
For many in the professional realm, an ecosystem lets you quickly see if something has promise - but if you decide to use it, you first sit down, understand the actual requirements of the technology, and then create a basis for achieving them compatible with your needs and ground rules of software practice.
You’ll find that true of many LoRaWAN starting points, in part because they are very hard problems that often get attention only after the basics are working. Join nonce (or frame count) storage is particularly thorny unless you assume battery backup, as you can’t just store the nonce with which you achieve success, but actually any you’ve tried since the failure could be in receiving the accept. But as common NVM tetchnologies including EEPROM have limited cycle life, in theory an orphaned node that stores everything could burn itself out, so some intermediate strategy may be warranted. One board design I’m aware of goes to the extreme of adding a MRAM chip for this…
There’s an additional problem that the SAMD21 on the MKRWAN 1310 does not have an EEPROM, the best you can do there is emulation by walking through flash. It happens that the STM32L0 radio processor does have EEPROM, so incorporating solution into the LoRaWAN stack could make sense… except that the strategy may need tuning by use.
One of the things often lacking in the LoRaWAN realm is good guidance on how to map the offerings of the network protocol to actual application needs - a lot of the discussion you’ll see here is down in the weeds of mechanics of problems like running the receiving window at the correct time, as while those first-tier issues dominate there’s less attention spared for considering the actual ideal operating strategy.