It seems very similar.
My google fu is failing me right now but FreeBSD also has a shared library used for reading/parsing config files and providing either a common or universal dsl for all conf files using the same library. This is one of the benefits of using an OS instead of a distribution - all the tools are developed holistically and refactors such as providing a shared, universal input or output format, sandboxing everything with capsicum, etc across the board are much more possible.
EDIT
Remembered it. Surprised at how bad Google was at finding this, though!
UCL - Universal Configuration Language [0]. Introduced in a paper by Allan Jude in 2015 [1]. Man page: libucl(3) [2].
[0]: https://github.com/vstakhov/libucl/
[1]: https://papers.freebsd.org/2015/bsdcan/allanjude-ucl/
[2]: https://man.freebsd.org/cgi/man.cgi?query=libucl&sektion=3&f...
Good programmers have long known that you should build your language up towards your application, and then write your language within that language. What tools are available to do that and where the line is drawn will vary. But you'll find customized languages buried in your database (SQL), configuration languages like https://github.com/vstakhov/libucl, specialized build configuration languages like make or ant, regular expressions for text matching, and so on.
Some languages encourage building external languages that you then parse and act on. Others encourage customizing an existing language to your needs. (Our Glorious Leader published a book in the mid-90s on doing that with Lisp, see http://www.paulgraham.com/onlisptext.html for details.) There have even been languages which are designed to be easily implemented in other languages, with whatever customizations you want. For example I personally worked with code from the 1980s that implemented a Forth variant to write financial models in.
But the idea doesn't have to be literally a new language. Squint sideways at any API, object model, or library and you can see it as a language. Conceptually there is a close parallel between scripting web services, and writing a TCL script that uses prebuilt commands written in C. If you can see the parallels and see how principles from the one apply to the other, the odds are that you'll be doing both better. Whereas if you don't see it and reinvent the wheel from scratch, you're going to wind up learning lessons the hard way that were learned many, many years ago.
All that said, writing and maintaining a language is significantly harder than writing business code. Therefore you'll always see rather more people writing code in languages, than writing languages to make code easy to write.
I implore you to NOT use JSON or ProtocolBuffers, neither are appropriate formats for configuring my shell, or storing long sets of textual data. Protocol Buffers is hardly the kind of format I want to parse and read my history in, and JSON is a less than ideal configuration format for many reasons.
https://github.com/vstakhov/libucl UCL (Universal Configuration Language) is a much more appropriate format for configuring programs than JSON, and is has been accepted as standard for use configuring all tools included in the FreeBSD operating system.
I also suggest you consider using a different language to store shell history, since shell history and shell configuration are two very different jobs with different goals and trade offs. I personally would suggest a simple safe format like TOML https://github.com/toml-lang/toml for storing the history.
But If you do want a single format for both configuration and history, I would implore you to pick TOML not JSON or Protocol Buffers.
There is also going to be influence from R and CSV files (which goes with awk).
I have thought about the config problem a lot -- and a configurable sandboxed "data mode" you are talking about is probably what I will go with.
If you squint, the oil shell will look not unlike nginx configs, e.g. a bunch of words with nested {} for blocks. Maybe like https://github.com/vstakhov/libucl or https://github.com/hashicorp/hcl (hm this seems to even have here docs!)
This kind of thing was done a lot with Python at my last job, to various degrees of success (e.g. https://bazel.build/ - the build language is derived from Python). Python sort of has some "data mode" sandboxing features, like being able to set __builtins__ when you exec/eval, but probably not enough. It didn't work well enough to prevent people from writing their own config file parser eventually. The syntax is close but not exactly what you want for some use cases.
Its syntax is nginx-like but can also parse strict json. It's pretty fast too.
More info here: https://github.com/vstakhov/libucl