test: [expected failures] function-library fixtures pending spec decisions

[leongdl]

Important

Expected-failure / spec-question fixtures — do not expect these to pass. Parked in EXPR/proposed/ (not discovered by the runner). Each asserts a strawman expectation and must not move into jobs/ until the spec question beside it is resolved or the bug is fixed. Details in proposed/README.md.

Contents (3 fixtures, dual-implementation verified)

• expr2.2.6--repr-py-newline-roundtrip — implementation bug in BOTH implementations: repr_py("a\nb") emits a raw newline inside the quotes (invalid Python literal; ast.literal_eval raises SyntaxError). §2.2.6 is explicit that repr_py follows Python's repr, which escapes. Move to jobs/ once fixed.
• expr2.2.4--center-odd-padding — spec gap, NO divergence: both implementations put the odd pad space on the RIGHT (matching Python str.center). §2.2.4 is silent on the split. The spec should document the de facto behaviour; then this fixture (with corrected expectation) goes live.
• expr2.2.4--isdigit-unicode — spec ambiguity, NO divergence: both implementations return false for isdigit("٣") (ASCII-only digits). §2.2.4 leaves "digit" undefined while §2.2.5 gives \d explicit Unicode semantics. Note the Python openjd CLI here deviates from native Python str.isdigit. The spec must define "digit"; the de facto agreement is ASCII-only.

Companion to the green-fixture PR from branch conformance-func-lib-gaps.

[leongdl]

Quorum verdict: NOT-GOOD (4/5 — three independent NOT-GOODs converged on the README) — spec: EL §2.2.4 center() is silent on the odd-split side, so 'spec question' is the right classification. But the README entry is wrong on the facts: (1) it claims both implementations return right-heavy ' hi ' with 'no divergence' — the 2026-08-12 sweep shows openjd-rs changed (upstream #305 + RFC 0005 coercion sync) and now emits CPython's ' hi '; only the Python CLI is right-heavy now (fails PYTHON only); (2) it misstates CPython — verified: 'hi'.center(7) == ' hi ' (extra space LEFT; left = pad//2 + (pad & width & 1) is not Python's formula); (3) it declares 'the fixture's left-heavy expectation was wrong' while the committed fixture still asserts ' hi ' — which now matches both CPython and openjd-rs. Action: rewrite the README entry to the sweep facts; the fixture's expectation can stand as the de facto pin, with the spec decision (document the CPython split) as the promotion gate.

[leongdl]

Quorum verdict: GOOD-WITH-NITS — spec: EL §2.2.4 leaves 'digit' undefined while §2.2.5 gives \d explicit Unicode semantics — correctly classified as a spec ambiguity, and the README's dual-run (both implementations ASCII-only, agreeing) matches the sweep. Nits: (1) the fixture header claims 'live implementation divergence' — there is none; both agree, the divergence is vs host-language str.isdigit — align the header with the README; (2) the strawman asserts Unicode-true, the OPPOSITE of the de facto agreement — if the spec ratifies ASCII (likely), the expectation flips; two reviewers suggest either flipping now or leaving this out of the inventory entirely since it prejudges an open spec decision rather than pinning a bug.

[leongdl]

Quorum verdict: GOOD (5/5, one stale comment) — spec: EL §2.2.6 (repr_py follows Python repr; the spec's own example escapes \n) — genuinely mandated, and the README's 'bug in BOTH implementations, dual-run verified' matches the sweep. The ast.literal_eval round-trip asserts semantics rather than byte-exact escaping — well built for promotion. Fix: the fixture's inline comment still says 'bug in openjd-rs' — update to both.

[leongdl]

Quorum review (5 independent agents). 3 fixtures + README. Net: 1 GOOD, 1 GOOD-WITH-NITS, 1 NOT-GOOD requiring a README rewrite before merge. The center-odd-padding README is internally contradictory and factually wrong about CPython (verified by execution: 'hi'.center(7) == ' hi ', extra space LEFT); per the 2026-08-12 sweep, openjd-rs now matches CPython and the PYTHON CLI is the outlier — the fixture's committed expectation actually matches the de facto answer, and the README is the defect. Cross-PR blocker: this branch and PR #164 both create EXPR/proposed/README.md (verified add/add conflict).

[leongdl]

Quorum-review fixes applied and pushed (rebased onto mainline 3069673):

• expr2.2.4--center-odd-padding README/header rewritten on the measured facts (the NOT-GOOD): CPython's 'hi'.center(7) is ' hi ' — extra space LEFT (verified by execution, three independent runs this review); current openjd-rs matches CPython (re-verified against an upstream/main build: emits ' hi '); the Python openjd CLI is now the right-heavy outlier. The fixture's committed expectation was correct all along — the old README's "both implementations are right-heavy / the expectation was wrong" claims are retracted in the new text.
• expr2.2.4--isdigit-unicode: header reframed as spec ambiguity with no divergence between the openjd implementations (both ASCII-only; the divergence is vs host CPython), and the strawman's flip-on-ASCII-ratification path is documented.
• expr2.2.6--repr-py-newline-roundtrip: stale "bug in openjd-rs" comment corrected to BOTH implementations.
• Restructured to kind-level parking (EXPR/jobs/proposed/) with a family-named README (README-func-lib.md) — removes the add/add merge conflict with test: [expected failures] EXPR fixtures needing implementation fixes #164.