Thanks for trying out KSON and having a look at the embed blocks. When embedding text inside text, the price/tax to delimit it must be paid somewhere, as the "KSON turducken" you've cooked up here demonstrates. We are familiar with this dish! Here's how we considered it in the design:

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/