bug: PPIx::Regexp exposes Unicode and object-cleanup regressions

[fglock]

Summary

PPIx::Regexp 0.092 exposes two PerlOnJava compatibility failures. The upstream suite passes on native system Perl, while PerlOnJava fails in both a Unicode source-compilation case and an object-cleanup assertion.

Observed during CPAN run 20260902-105744-25704:

• System Perl: 13,264 tests pass across 10 test programs.
• PerlOnJava: 5,307/5,308 subtests pass; 2/10 test programs fail.

PPIx::Regexp and its PPI dependency are pure Perl, so this is not an XS-availability issue.

Failure 1: invalid Unicode character name

t/parse.t deliberately tests an illegal Unicode code point using:

$delim = "\N{U+11FFFF}";
tokenize("qr ${delim}x$delim");

Native Perl accepts the test source and the parser test completes. PerlOnJava aborts before the test can run with:

Unknown charname 'U+11FFFF' at t/parse.t line 11930, within string

This appears to belong at the Unicode named-character/compiler boundary rather than in PPIx::Regexp itself. The implementation should distinguish an intentionally invalid code point used as string data from an unknown named character in a context where Perl rejects it.

Failure 2: retained PPIx::Regexp objects

t/unit.t ends with:

finis();

The helper clears its test references, pauses, and checks:

$result = PPIx::Regexp::Element->__parent_keys();
is($result, 0, 'Should be no leftover objects');

Native Perl reports zero retained objects. PerlOnJava reports:

got: 671
expected: 0

This suggests that parent/key bookkeeping, weak references, caches, or destruction of the PPIx::Regexp object graph is retaining objects after the test scope releases them. It should be investigated independently from the Unicode failure.

Suggested investigation

1. Reduce the U+11FFFF case to a project-owned string/compiler test with a valid Unicode control and an ordinary unknown-name control.
2. Compare native Perl and both PerlOnJava backends for diagnostics, warning behavior, and whether the failure occurs during string interpolation or regex construction.
3. Trace the object graph created by PPIx::Regexp::Element and the implementation of __parent_keys().
4. Check weak-reference and cache cleanup after parsing a single expression and after parsing the full unit.t sequence.
5. Determine whether the cleanup count is affected by the earlier Unicode parser state or is an independent lifecycle defect.

Acceptance criteria

• The U+11FFFF upstream parse case completes with system-Perl-compatible behavior on both PerlOnJava backends.
• Unknown named characters in genuinely invalid contexts continue to produce the correct diagnostic.
• PPIx::Regexp::Element->__parent_keys() returns zero after the documented object references are released.
• PPIx::Regexp 0.092 passes its upstream suite on the JVM and interpreter backends.
• Permanent focused tests cover both failure clusters and include positive controls.