There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references.
The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data.
libcli could also be used to produce structured program outputs which then can be fed into applications, possibly skipping the serialisation deserialization steps.
Since libcli will have a standard interface each distro can choose their own CLI format or whether they output their data as JSON or CBOR.
In both cases the benefit is that the choice of the data storage mechanism has been decoupled from the application.
I mean, the versioning part sounds good, but JSON like request?
I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.
It's tooling created for security and forensics that tries to manually read it.
Registry settings already have ACL items applied. You can see this behavior if you log in as a non admin user then try to view another users registry settings.
https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... The thing is pretty free form with a choice of some very basic data types dword/qword and strings ascii/unicode/lists of strings.
Adding a wrapper around the existing call to go towards a json schema registry could be a helpful thing.
Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc.
This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server can respond in version 4 format.
With a service it doesn't matter if things are stored as a single sqlite DB or as multiple files.