Thanks. This may serve as an example.
My goal is to be able to use non-volatile memory of arbitrary type, not just RTC memory (which has a limited lifetime for the number of writes per cell) and not only for ESP32.
Getting and setting state is something that should be implemented in the LMIC library itself. Any state implementation details and its intricasies should be encapsulated from clients that are using the library.
The responsibility of the application would be to save and restore the state to/from volatile memory. The type of volatile memory used is a client dependent implementation detail and not the responsibility of the LMIC library.
The ESP32 specific LMIC fork mentioned uses ESP32 RTC memory but that is limited to both ESP32 and its RTC memory. From design perspective the saving and restoring of state to/from (whatever form of) non-volatile memory should not be done in the LMIC library.