From there it could be compiled to targets declarative or procedural (eg to generate VegaLite specs, echart specs or Observable Plot configs in JS).

How have you been thinking about this problem space?

KSON (stands for: KSON Structured Object Notation) is designed not as an nth standard, but rather as an idea of how to play nice with all n-1 existing standards. Since our comments (we do support comments!) are preserved in formatting and transpilation (provided the underlying language supports comments), you may use KSON as how you edit whatever underlying config file your system wants (currently YAML and JSON are supported, with a clear path to adding other targets like TOML <https://github.com/kson-org/kson/issues/202>)

Why is it better than TOML? We don't insist that everyone agree it is! But here's two ways to contrast them: - We prefer that KSON's recursive structure makes nesting consistent. You can see for instance in the grammar that a Kson list value is a list of Kson values: https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5... - For use cases where folks are hand-editing non-trivial config, especially if they are using embedded code blocks of any kind: if they long for more help from their tooling, KSON makes that tooling possible.

By making the content type of the embed a first-class citizen of the syntax, together with clear boundaries for the embedded content, editors and IDEs can hook in all their great tooling to the embed blocks. So, you nailed it: being great for devex is exactly the idea.

Our design observes that triple+ embedded KSON embed blocks should be rare and are zany enough information architecture that we do not need to cater to them. We accommodate singly-embedded KSON by offering `$/$$` as an alternative embed delimiter that can be used to minimize escaping (fun: if you paste your example in the playground <https://kson.org/playground/> and format it, the formatter will minimize the escaping for you).

The two-char end-delimiter is important to make it trivial to describe the end of a embed block: a `%` embed block ends if and only if exactly `%%` is encountered. This is designed to make it dead simple for humans and (especially) tools to understand the bounds of an embed.

Zig's manually-managed margin approach is interesting. Paying the embedded text price/tax with a manually managed margin is inventive, and does indeed give good whitespace control and skips all escaping. However, having to always manage that margin goes against our goal of having embed blocks facilitate "pure" embedded editing as much as possible---every block that does not contain `%%` can be edited completely in the block's native language.

Hopefully that helps make some of our goals and design decisions more clear. We've worked hard to minimize the cost of embedding while maximizing the clarity, utility and toolabilty of it. Definitely open to ideas on improving our min/max'ing here if folks see opportunities. Come chat with us on Zulip if you've got thoughts! https://kson-org.zulipchat.com/