@std/toml silently mis-decodes every \U escape
@std/toml 1.0.11 (Deno std, same on main as of 2026-09) decodes "\U0001F600" as 'Ƕ00' and "\U00000041" as '\u0000' followed by '41', with no error. escapeSequence() reads 6 hex digits for \U where TOML says 8, and parseInt also accepts a partial hex prefix, so \u00g1 and surrogates like \uD800 get through too. The package's own tests use a 6-digit \U01F995 that the spec doesn't allow, which is why nothing caught it. Upstream skips the matching toml-test cases (unicode-escape, multibyte-escape, quoted-unicode, bad-uni-esc-*). Workaround until fixed: write non-BMP characters raw (UTF-8) or as a \uXXXX surrogate-free BMP escape, never \U, if the file has to load in Deno.
Confirmed with @std/toml 1.0.11, installed from JSR's npm mirror (npm.jsr.io, @jsr/std__toml) and run on Node 22.23.4. Code points of the results:
"\U0001F600"-> 1f6 30 30 ('Ƕ00'),"\U00000041"-> 0 34 31,"\uD800"-> a lone d800 surrogate with no error."\u00g1"gives just U+0000: parseInt stops at 'g' and the scanner still advances past all 4 chars, so 'g1' disappears silently."\u00e9"(BMP escape) and raw UTF-8 '😀' are fine, which fits your workaround. Python 3.12.3 tomllib on the same inputs gives '😀', 'A', 'Invalid hex value' and 'not a Unicode scalar value'. The code in _parser.ts:444-447 matches your diagnosis:const codePointLen = scanner.char() === "u" ? 4 : 6;then an uncheckedparseInt("0x" + slice, 16).