I think ideally, an export option might be to export your table as code-ready content; in your case, a complete array definition in a more or less standard form, such as:
constexpr int table[][] = {
{val, val, val},
.
.
.
{val, val, val},
{val, val, val}
};
which is instantly pasteable into the user's .ino file. Saves the drudgery of formatting.
But then, I already do this for my config tables for my Nano network's servo nodes. Just never thought it would be of interest.
If you're curious, here's an example. In an Excel file, I can generate 12 different node definitions, all similar to:
//-------------------------------- OBA WEST -------------------------------------------------
#ifdef OBAW
#define NODENAME "OBAW"
#define NODENUM 8
#define NODFLT //if this is not defined, code creates a standard 16 TO, 32 LED node, no routes
#define HAS23017 false
#define HAS9685 false
Button Buttons[] = { 18, 57, 95, 128, 162, 203, 243, 280, 320};
Turnout Turnouts[] = {
// st ty Pn | rm lc Bn | hA | tA | -- hL | -- tL | hs hk hf hT | ts tk tf tT 20250301
{HOME, SRVO, 3, LOCL, YARD, 0, 31, 29, 0, 0, 0, 1, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 0
{HOME, SRVO, 4, LOCL, YARD, 1, 31, 29, 0, 2, 0, 3, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 1
{HOME, SRVO, 5, LOCL, YARD, 2, 31, 29, 0, 4, 0, 5, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 2
{HOME, SRVO, 6, LOCL, YARD, 3, 31, 29, 0, 6, 0, 7, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 3
{HOME, SRVO, 7, LOCL, YARD, 4, 31, 29, 0, 8, 0, 9, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 4
{HOME, TORT, 8, LOCL, MAIN, 5, 31, 29, 0, 10, 0, 11, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 5
{HOME, TORT, 9, LOCL, MAIN, 6, 31, 29, 0, 12, 0, 13, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 6
{HOME, SRVO, 10, LOCL, MAIN, 7, 31, 29, 0, 14, 0, 15, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 7
{HOME, SRVO, 11, LOCL, MAIN, 8, 31, 29, 0, 16, 0, 17, THRN, NORM, NLNK, 0, HOME, NORM, NLNK, 0 }, //Turnout 8
};
Route Routes[][ROUTELEN] = {
{ 'A', -1, -1, -1, -1, -1, -1, -1, -1, -1}, //
{ 'a', 'B', 'C', 'D', 'E', -1, -1, -1, -1, -1}, //
{ 'a', 'B', 'C', 'D', 'e', -1, -1, -1, -1, -1}, //
{ 'a', 'B', 'C', 'd', -1, -1, -1, -1, -1, -1}, //
{ 'a', 'B', 'c', 'g', -1, -1, -1, -1, -1, -1}, //
{ 'a', 'B', 'c', 'g', -1, -1, -1, -1, -1, -1}, //
{ 'a', 'b', 'f', -1, -1, -1, -1, -1, -1, -1}, //
{ 'a', 'b', 'F', 'g', -1, -1, -1, -1, -1, -1}, //
{ 'a', 'B', 'F', -1, -1, -1, -1, -1, -1, -1}, //
}; //end of routes table - 9 routes
#endif //END of OBAW
These definitions are output to a file named locations.h; as you can see, they are compiler-ready. My .ino file simply pulls in the correct definition from the above output file, in this case by
#define OBAW //must occur before locations.h inclusion
#include "locations.h"
And the dataset for OBAW is incorporated in my config program in a Nano. My config program then writes the Nano EEPROM with the OBAW configuration. A second program is then written to the Nano, which simply reads and implements the EEPROM configuration; all nodes contain the same code; their personality, if you will, is defined by the EEPROM content.
Hope that gives you some ideas for extensions of what looks like a great beginning!
Best of luck, have fun!