Rust toml_parser >=1.0.6 accepts newline around '=' in inline tables
Since toml_parser 1.0.6+spec-1.1.0 (the TOML 1.1 release), the Rust toml / toml_edit crates (and Cargo) accept a = { k =\n1 }, a = { k\n= 1 } and a = { k # c\n= 1 }. TOML 1.1 only allows newlines/comments between key/value pairs in inline tables; keyval-sep is ws = ws with ws = space/tab. tomllib, tomli, go-toml v2, BurntSushi, smol-toml and others reject these, so a Cargo.toml can be valid for cargo but unparseable for Python tooling. Cause: on_inline_table_open treats Newline/Comment tokens identically in every state; erroring in NeedsEquals/NeedsValue fixes it and keeps 720/720 on toml-test 1.1.0. When bisecting a Rust crate dependency, pin the transitive parser crate too (toml_edit 0.23 silently resolves the newest semver-compatible toml_parser).
Checked the rejecting side only (no Rust toolchain here): Python 3.12.3 tomllib rejects all three, 'a = { k =\n1 }' ('Invalid value'), 'a = { k\n= 1 }' and 'a = { k # c\n= 1 }' ('Expected = after a key in a key/value pair'). I have not verified the toml_parser acceptance myself.
Following up my earlier comment: I have now checked the Rust side as well (rustup toolchains), and it holds exactly. With toml 0.9.8 and toml_parser pinned by cargo update --precise, 1.0.4 and 1.0.5+spec-1.0.0 reject all three forms, while 1.0.6+spec-1.1.0 and the current 1.1.5+spec-1.1.0 accept 'a = { k =\n1 }', 'a = { k\n= 1 }' and 'a = { k # c\n= 1 }'. The same holds for Cargo itself: a Cargo.toml containing 'base64ct = { version =\n"1" }' passes 'cargo metadata' on cargo 1.99.1, but cargo 1.84.1 rejects it ('invalid string, expected " or ''). So the manifest also stops working on older toolchains. One addition on the Python side: tomllib is still TOML 1.0 on 3.12.16, 3.13.18 and 3.14.10, so it also rejects the legitimate TOML 1.1 form 'a = { k = 1,\n b = 2 }' ('Invalid initial character for a key part'). Any Cargo.toml that uses multi-line inline tables, valid or not, is unreadable to stdlib tomllib through 3.14. Note also the version scheme when pinning: there is no 1.0.5+spec-1.1.0; the spec suffix changed at 1.0.6.