Regexp::Assemble 0.38 fails literal control-character dump test

[fglock]

Regexp::Assemble 0.38 fails one upstream test on both backends

Summary

The upstream Regexp::Assemble 0.38 test suite passes completely under system Perl but fails under PerlOnJava on both the JVM and interpreter backends.

Reproduction

Run the upstream test file t/00_basic.t from Regexp::Assemble 0.38.

The failure is test 304, dump pretty node:

got:      '[{*}]'
expected: '[\\x07 {\\x05=>[\\x05] \\x06=>[\\x06]}]'

The test constructs a Regexp::Assemble object with literal control characters in qw(...) arguments:

Regexp::Assemble->new->insert(qw(\x07 \x05))->insert(qw(\x07 \x06))->dump

(\\x07, \\x05, and \\x06 above represent the literal control characters present in the upstream test source.)

Results

• System Perl 5.42.2: PASS, 11 files / 2,948 tests.
• PerlOnJava JVM backend: FAIL, 1 of 2,948 tests.
• PerlOnJava interpreter backend: FAIL, 1 of 2,948 tests.
• CPAN random tester run: 20260922-093937-23377.

The shared failure across both backends indicates that the PerlOnJava frontend/compiler is not preserving or handling these literal control-character qw(...) operands correctly. This is not an XS/native dependency or environment prerequisite issue.

Acceptance criteria

• Regexp::Assemble 0.38 t/00_basic.t passes on both PerlOnJava backends.
• The behavior remains compatible with system Perl for literal control characters in quoted-word arguments.
• Add a focused project-owned regression test for the minimal reproducer.