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

conformance-tests/2023-09/EXPR/jobs/proposed/README-func-lib.md

@@ -0,0 +1,54 @@
+# Proposed EXPR fixtures (function library) — jobs
+
+Fixtures listed here are parked instead of live, because a reference
+implementation fails them or because the spec is silent on the behaviour
+they pin. Placement is kind-level (`<component>/<kind>/proposed/`);
+promotion is a mechanical move up one directory. The runner does not scan
+`proposed/`. This README is named per fixture family
+(`README-func-lib.md`) because other expected-failures PRs park fixtures
+in this same directory with their own READMEs.
+
+Observations are per-implementation (`rs` = openjd-rs, `py` = the Python
+openjd CLI); dual results from the 2026-08-12 sweep, re-verified against
+the current upstream/main rs build where noted.
+
+## `expr2.2.4--center-odd-padding.test.yaml` — spec silence, py outlier
+
+§2.2.4 does not say which side of `center()` receives the extra space for
+odd padding. Measured for `center("hi", 7)`:
+
+| Engine | Output | Extra space |
+|---|---|---|
+| CPython `str.center` | `'   hi  '` | LEFT (verified by execution) |
+| openjd-rs (current upstream/main) | `'   hi  '` | LEFT — matches CPython (changed by upstream #305 + RFC 0005 coercion sync; re-verified this session) |
+| Python openjd CLI | `'  hi   '` | RIGHT — now the outlier |
+
+The fixture asserts the CPython/rs behaviour — the de facto answer.
+Classification: **spec decision needed** ("follow CPython" would make this
+promotable and the Python CLI's split a plain bug). An earlier revision of
+this README claimed both implementations were right-heavy and that the
+fixture's expectation was wrong; both claims were incorrect (rs changed,
+and CPython is left-heavy).
+
+## `expr2.2.4--isdigit-unicode.test.yaml` — spec ambiguity, no divergence
+
+§2.2.4 never defines "digit". Both openjd implementations agree on
+ASCII-only (`isdigit("٣")` is false on rs AND py); CPython's host
+`str.isdigit` says True; §2.2.5 gives `\d` explicit Unicode semantics.
+The fixture asserts the Unicode reading as a strawman — the OPPOSITE of
+the current de facto agreement. Classification: **spec decision needed**
+(define "digit"; ASCII-only is the likely ratification given both
+implementations agree, in which case flip the expectation rather than
+promote as-is).
+
+## `expr2.2.6--repr-py-newline-roundtrip.test.yaml` — bug in BOTH
+
+§2.2.6: repr_py "follows the behavior of Python's repr", whose example
+escapes `\n`. BOTH implementations emit a raw newline inside the quoted
+literal, producing invalid Python (`ast.literal_eval` raises
+SyntaxError). Classification: **implementation bug in both**; the spec is
+explicit. Promote once fixed. End-to-end twin through WRAP_ACTIONS
+forwarding: `WRAP_ACTIONS/jobs/proposed/
+wrap-repr-py-escapes-newline-in-wrapped-args.test.yaml` (wrap-actions
+expected-failures PR) — note that twin is additionally gated on the §5.2
+ArgString newline question.

conformance-tests/2023-09/EXPR/jobs/proposed/expr2.2.4--center-odd-padding.test.yaml

@@ -0,0 +1,36 @@
+# PARKED: spec-silent behaviour with a live implementation divergence.
+#
+# Expression Language §2.2.4 specifies center(s, width) only as "Center, pad
+# with spaces to width" — it does not say which side receives the extra space
+# when the padding is odd.
+#
+# Observed for center("hi", 7) (5 pad spaces to split), 2026-08 measurements:
+#   CPython str.center:   "   hi  "  (3 left, 2 right — extra space LEFT;
+#                          left = (width - len) // 2 + ((width - len) & width & 1))
+#   openjd-rs:            "   hi  "  (matches CPython since upstream #305 +
+#                          the RFC 0005 coercion sync; verified again on the
+#                          current upstream/main build)
+#   Python openjd CLI:    "  hi   "  (2 left, 3 right — now the OUTLIER)
+#
+# The expected: block below asserts the CPython/openjd-rs behaviour, which
+# has become the de facto answer. Do NOT move this fixture into jobs/ until
+# the spec picks a side ("follow CPython" would make this promotable and the
+# Python CLI's split a plain bug).
+template:
+  specificationVersion: jobtemplate-2023-09
+  extensions:
+  - EXPR
+  name: TestJob
+  steps:
+  - name: Step1
+    script:
+      actions:
+        onRun:
+          command: python
+          args:
+          - -c
+          - |
+            print(r'CENTER:[{{ center("hi", 7) }}]')
+expected:
+  output:
+  - "CENTER:[   hi  ]"

conformance-tests/2023-09/EXPR/jobs/proposed/expr2.2.4--isdigit-unicode.test.yaml

@@ -0,0 +1,40 @@
+# PARKED: spec ambiguity — NO divergence between the openjd implementations.
+#
+# Expression Language §2.2.4 specifies isdigit(s) as "True if all characters
+# are digits and string is non-empty" without defining "digit": ASCII 0-9 or
+# Unicode digit category (Nd)? §2.2.5 explicitly gives \d Unicode semantics,
+# which pulls one way; both openjd implementations pull the other.
+#
+# Observed for isdigit("٣") (U+0663 ARABIC-INDIC DIGIT THREE):
+#   openjd-rs:              false  (ASCII-only digit test)
+#   Python openjd CLI:      false  (agrees — ASCII-only)
+#   CPython str.isdigit:    True   (Unicode Nd/No digit test — the host
+#                                   language differs from both)
+#
+# The expected: block below asserts the Unicode reading as a strawman,
+# matching §2.2.5's Unicode posture — i.e. the OPPOSITE of the current
+# de facto agreement. If the spec ratifies ASCII-only (the likely outcome
+# given both implementations agree), flip the expectation instead of
+# promoting as-is. Do NOT move this fixture into jobs/ until the spec
+# defines "digit" (and likewise "alphabetic"/"alphanumeric"/"whitespace"
+# for the sibling predicates).
+template:
+  specificationVersion: jobtemplate-2023-09
+  extensions:
+  - EXPR
+  name: TestJob
+  steps:
+  - name: Step1
+    script:
+      actions:
+        onRun:
+          command: python
+          args:
+          - -c
+          - |
+            print(r'ISDIGIT_ARABIC:{{ isdigit("٣") }}')
+            print(r'ISDIGIT_DEVANAGARI:{{ isdigit("३") }}')
+expected:
+  output:
+  - ISDIGIT_ARABIC:true
+  - ISDIGIT_DEVANAGARI:true

conformance-tests/2023-09/EXPR/jobs/proposed/expr2.2.6--repr-py-newline-roundtrip.test.yaml

@@ -0,0 +1,45 @@
+# PARKED: implementation bug found by the repr_py round-trip battery.
+#
+# Expression Language §2.2.6: repr_py "follows the behavior of Python's repr".
+# Python's repr("a\nb") is 'a\nb' (backslash-n ESCAPED, 7 characters, one line).
+# BOTH implementations (openjd-rs and the Python CLI — 2026-08-12 sweep) emit
+# a RAW newline inside the single quotes — which is not a valid
+# Python string literal at all:
+#
+#   ast.literal_eval on the emitted output raises
+#   "SyntaxError: unterminated string literal (detected at line 1)"
+#
+# So the output cannot be embedded in a generated Python script, which is the
+# entire purpose of repr_py. Backslash, quote, and tab handling round-trip
+# correctly (tab is emitted raw rather than as \t, which deviates from repr()
+# but still parses back byte-identical); newline is the case that produces
+# invalid output. Classification: implementation bug in BOTH implementations
+# (spec is
+# explicit via the repr() reference). This fixture is the regression test to
+# move into jobs/ once fixed.
+template:
+  specificationVersion: jobtemplate-2023-09
+  extensions:
+  - EXPR
+  name: TestJob
+  steps:
+  - name: Step1
+    let:
+    - 'q = repr_py("a\nb")'
+    script:
+      actions:
+        onRun:
+          command: python
+          args:
+          - -c
+          - |
+            import ast
+            import sys
+            got = ast.literal_eval(sys.argv[1])
+            print("NEWLINE:" + ("PASS" if got == "a\nb" else "FAIL got=" + repr(got)))
+          - "{{ q }}"
+expected:
+  output:
+  - NEWLINE:PASS
+  forbidden:
+  - FAIL