src/backend/executor/execRPR.c

Use the reluctant variant (confirmed COVERS 1185/1186/1187 in isolation):
WITH t(id,isa) AS (VALUES (1,true),(2,true),(3,false))
SELECT id, count(*) OVER w
FROM t
WINDOW w AS (ORDER BY id
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
PATTERN (((A??){2,}?){2,}?)
DEFINE A AS isa)
ORDER BY id;
-- This survives optimizer flattening because reluctant quantifiers disable tryFlattenNestedQuantifier (rpr.c:797), keeping the doubly-nested group so the inner END->next is the outer END.
Do NOT rely on the greedy ((A?){2,}){2,} variant -- it is flattened to a single group and does NOT cover these lines.
A greedy alternative that DOES work (verified, 4 hits each) needs a multi-child nullable inner body so it resists flatten/unwrap:
WITH t(id,v) AS (VALUES (1,'x'),(2,'x'),(3,'x'),(4,'x'))
SELECT id, count(*) OVER w AS c
FROM t
WINDOW w AS (ORDER BY id
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
PATTERN ( (X (A? B?){2,}){2,} )
DEFINE X AS v='x', A AS v='a', B AS v='b')
ORDER BY id;
-- Add at least the reluctant P1 to rpr.sql;
optionally add the greedy P3 too, to also exercise the greedy else-branch fast-forward (lines 1219-1223) which P1 leaves uncovered.

VERIFIED REACHABLE and the originally proposed reluctant test DOES cover lines 1185-1187, but the claim's GREEDY variant is WRONG.
Lines 1186-1187 are the END->END count increment in the EMPTY_LOOP fast-forward path (count < elem->min branch).
They run when a nullable group's END->next (set sequentially by finalizeRPRPattern at rpr.c:1453-1454 to i+1) lands on an outer END element, i.e. the nullable group is the last child of an enclosing quantified group.
I rebuilt coverage data (this is a -fprofile-arcs build) and ran candidates one-per-server-lifecycle (full stop/rm-gcda/start/stop, since the running postmaster only flushes .gcda reliably on clean exit;
sloppy resets between runs gave false positives AND false negatives that initially misled me).
Clean isolated results:
P1 reluctant ((A??){2,}?){2,}? -> line 1185 6 hits with IS-END branch taken 50%, line 1186 3 hits, line 1187 3 hits = COVERED.
P3 (X (A? B?){2,}){2,} -> 4 hits each = COVERED.
P2 greedy ((A?){2,}){2,} -> line 1186 #####  = NOT COVERED: tryFlattenNestedQuantifier (rpr.c:797 skips flatten only for reluctant) collapses the nested greedy groups into one {4,} group, destroying the nested END->END so elem->next becomes FIN not an outer END.
Also note single-child nullable groups like (B?){2,} get flattened to B* (child->min==0 -> safe at rpr.c:812), so the inner group needs a multi-child SEQ body OR reluctant quantifiers to survive.
The original claim that 'A greedy variant also exercises the END->END increment via the greedy else-branch' is refuted;
the greedy else-branch (1218-1223) is never even reached by that pattern.

Add to rpr_nfa.sql a window using a reluctant nullable group followed by a REQUIRED element so the fast-forward exit lands on that element (not FIN), forcing fall-through to the loop-back at line 1213. Verified covering pattern (1195=6, 1213=6, 1209 not hit):

WITH cov AS (
SELECT id, count(*) OVER w AS c
FROM t
WINDOW w AS (ORDER BY id
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
PATTERN ((A??){2,}? B)
DEFINE A AS isa, B AS isb)
)
SELECT *
FROM cov
ORDER BY id;

with table t(id int, isa bool, isb bool) rows (1,t,t),(2,t,t),(3,f,f),(4,t,t),(5,t,t).
Equivalently ((A??)+? B) also covers it.
The NOT-working proposed pattern (((A??){2,}?){2,}?) must be replaced by one with a required follower.

Line 1195 is the opening brace of the reluctant branch (1194: ffState != NULL && RPRElemIsReluctant(elem)) in the count<min path.
It is genuinely reachable and testable, but the PROPOSED nested pattern (((A??){2,}?){2,}?) does NOT cover it.
I verified each pattern in isolation against a coverage build (gcda flushes only on backend exit, read in a separate step to avoid a race that earlier produced bogus 'covered' readings).
The nested pattern alone: 1194=10 (branch entered) but 1195=##### and 1213=#####, because the nested reluctant END's fast-forward still reaches FIN, so it always returns at line 1209 -- identical to the existing rr2 ((A??){2,}?) test.
Line 1195's basic block is specifically the fall-through-to-1213 path (reluctant exit did NOT reach FIN, so 1206 is false).
That path requires a REQUIRED element after the nullable reluctant group.
The B-follower variant ((A??){2,}? B) with A AS isa, B AS isb gives 1195=6, 1213=6, 1209=##### -- it covers the line.
The claim that the nested pattern covers 1195 is refuted;
only the required-follower variant works.

The proposed test is correct as-is and covers line 1213 (verified, count 7).
One practical caveat for adding it to the regression suite: a
VALUES/CTE-based source (WITH t(id,f) AS (VALUES ...)) parses and runs fine, but to match existing rpr.sql style and avoid any deparse/array-literal edge cases, prefer a real table:

CREATE TABLE tt(id int, f text[]);
INSERT INTO tt
VALUES (1,ARRAY['A']),(2,ARRAY['A']),(3,ARRAY['B']),(4,ARRAY['X']);
SELECT id, first_value(id) OVER w AS s, last_value(id) OVER w AS e
FROM tt
WINDOW w AS (
ORDER BY id
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
AFTER MATCH SKIP PAST LAST ROW
PATTERN ((A??){2,}? B)
DEFINE A AS 'A'=ANY(f), B AS 'B'=ANY(f))
ORDER BY id;

Expected output (verified): row id=1 -> s=1,e=3;
rows id=2,3,4 -> NULL,NULL.
The reluctant nullable group with min=2 plus required follower B that does not match at the group's exit row is the essential ingredient;
keep that shape.

CONFIRMED reachable and CONFIRMED the proposed test drives execution through line 1213 exactly.
Verified empirically, not by reasoning alone.
Line 1213 is the 'loop-back second' nfa_route_to_elem call in the reluctant nullable-group branch (count < min, RPRElemCanEmptyLoop true, RPRElemIsReluctant true).
It executes only when the reluctant fast-forward exit at 1199 does NOT reach FIN, leaving ctx->matchedState == savedMatch so the 1206 test takes the FALSE side and falls through to 1213. The root cause's explanation of the gating condition is accurate.

Empirical proof: rebuilt/started the correct PostgreSQL 19beta1 coverage build (the default psql socket had been silently connecting to an unrelated system PostgreSQL 18.3, and the project PGDATA had a PG_CONTROL_VERSION 1901 vs 1902 mismatch -- so I ran initdb on a fresh temp cluster on port 5444 with the just-built binary).
I removed execRPR.gcda to zero counters, ran ONLY the proposed query, stopped the server to flush gcov data, and regenerated the .gcov.
Result: line 1213 shows execution count 7 (covered), while lines 1208-1209 (the FIN-reached early-return path) show ##### (0) in this isolated run -- exactly the 'loop-back second taken because fast-forward did not reach FIN' scenario the finding predicts.
Pattern ((A??){2,}? B) with min=2 reluctant nullable group followed by required B, input A,A,B,X, produced match {id 1..3} and exercised the loop-back-second route.
Classification 'testable' is correct.