The OpenBSD approach is to have one language per configuration format, using a common lexer (.c code written by hand but similar across programs, splitting keywords and special characters), but specific parser (using yacc).

The advantage is to have a single file, with macro (var = "xxx"), include support, and a syntax efficient for the actual format to read. OTOH, this requires YACC.

The DJB Way [1] is to have multiple files, closer to what you zge seems to be doing, but each file still a "table", that containt the bulk of the data (like in http://cr.yp.to/djbdns/tinydns-data.html), or individual (like in the various qmail-* programs, each reading a subset of /var/qmail/control/* files).

Then, there are more formal syntax, like .ini, .json, .toml, .yaml (;_;), .hcl... That are built like a tree, or programing languages (.h header file to recompile, external conf.lua for project in C, .py for .py project...).

I had this idea that a configuration built like a tree could continue the filesystem tree:

If /etc/myprog/test.json is a file, /etc/myprog/server/runners/memory would open that file then go to ."server"."runner"."memory" within json (jq syntax).
If /etc/myprog/test/server is a file, /etc/myprog/server/runners/memory would open that file then go to ."runner"."memory" with json (jq syntax).