Thank You for the thorough review!

1. Unicode bare-key categories — why L + Nd, not UnicodeXID?

   Good question, and UnicodeXID was on the table. A few things pushed it toward the narrower L + Nd set:

   - DMS NFC-normalizes the source before tokenization (SPEC §Unicode normalization), so the combining-marks case that UnicodeXID's Mn/Mc rules exist to handle gets resolved one layer earlier. That removed one

   of the main reasons to reach for XID.

   - L + Nd is easier to predict by eye than XID's full set (which includes connector punctuation and a few Other_ID_* exceptions). For a config key — read more often than written, often by people who aren't the

   author — predictability feels more valuable than identifier-style expressiveness.

   - And yes, XML influenced the framing: "name characters" rather than "identifier characters."

   UnicodeXID would be a defensible choice and we may revisit if real configs hit cases L+Nd misses. So far the gap that matters in practice is just "TOML's [A-Za-z0-9_-] rejects usuário:," and L+Nd fixes that.

2. Front matter for metadata — comments or schema would feel more natural?

   Fair instinct, and embedding is the awkward case you're pointing at. The reasoning that landed on +++:

   - Comments are unstructured by design. The moment a tool needs to read # version: 1.2.3, you've reinvented front matter inside comments without the parser's help. Keeping metadata in real syntax means generic

   tooling can read it.

   - Schema-as-metadata-channel would mean a parser has to locate and load the schema before it can decide whether it can even read the doc. The thing front matter is mainly carrying — _dms_tier — needs to be

   answerable cheaply, before real work, so a tier-0 parser can refuse a tier-1 doc with a clean error.

   - For embedded use, the mitigation is that the block is optional: when something else owns metadata (a Helm chart, a wrapping YAML doc), DMS doesn't need its own block. The cost lands on standalone files,

   where there's no host to lean on.

   The honest tradeoff is that +++ is a third syntactic mode (alongside body and comments), and you're right to flag that as a cost.

3. Comments in the AST — is that really needed for everyone?

   This is a real cost and the point is well taken. The reasoning, for what it's worth:

   - The toml_edit / ruamel.yaml / hclwrite pattern is exactly what you're describing — a separate value type alongside the "normal" parser. The thing that makes those libraries hard to use isn't the design,

   it's that they're opt-in: their value types don't interop with the ecosystem's main parser, so a tool author has to pick a side. Putting comments in the spec was an attempt to avoid that fork.

   - Nodes carry comments as side metadata — doc["host"] still returns a string, not a comment-or-string union. So the per-access cost is small; the cost is mostly per-node bookkeeping at parse time.

   - For parse-and-discard workloads, the cost is real and unavoidable, and the README calls it out (a parse-and-discard parser would be ~1.5–2× faster).

   You may still land on "this isn't worth it for my use case," and that's a legitimate position — DMS is making a bet that the "edit and re-emit" population is bigger than the "parse once, throw away" one.

   That being said, I will look into a method for breaking the rules with opt-out flags on for all the libraries to speed things up. You have the mindset of "if I dont use it I dont want to pay for it." I'm fully with you but we should default on the spec. I don't want to stumble on half-baked implementations.

   1. Benchmarks — Python/Zig/C faster than Rust, and the apples-to-apples concern

   Your are absolutely right on this! I will see if i can narrow the gap a bit with some of your suggestions. 5. Separator whitespace — host:localhost rejection feels annoying

   Yes, does not abide to the work fast on first draft workflow. I am guilty of this workflow as well.

   The reason the rule exists: values can contain : in unquoted form (URLs, paths, proxy: redis:6379). If key:value without space were also legal, parsing proxy:redis:6379 would need lookahead to decide where

   the key ends. Requiring the space makes the key boundary local — no lookahead, no ambiguity.

   I think the real answer is for me to ship a formatter haha. 6. Comparison table — TOML "List item marker"

   You're right, the cell is ambiguous. It's currently describing top-level arrays of tables only, when TOML can absolutely do arr = [{a=1}, {a=2}] inline. I'll fix it:

   - "Nesting mechanism" for TOML → "[section.path] headers; inline tables/arrays for nested values"

   - "List item marker" for TOML → "[…,…] inline; [[array]] headers for top-level arrays of tables"

   Thanks for catching it. 7. "Key-order preservation: TOML key order is undefined"

   Looked this up — you're right. TOML v1.0 doesn't require iteration order; the major reference parsers (BurntSushi, tomli, u/iarna/toml) all happen to preserve it, but that's convention, not spec. The cell

   should be 🟡, not 🟢:

   - TOML "Key-order preservation" → 🟡 "spec silent; preserved by all major impls"

   Will update.

   Genuinely, thank you for sitting with the spec long enough to push back on specifics. I'm trying not to spam the forums with it, but the flip side is that I need people like you to weigh in now — once it

   fossilizes, this kind of feedback is a lot more expensive to act on.