SQL/PGQ: quantified path patterns unsupported in GRAPH_TABLE (19beta2/beta3) — known gap or on the roadmap?

Hi all,

I've been writing a hands-on PostgreSQL book [1] and put together a
chapter on the new SQL/PGQ support (CREATE PROPERTY GRAPH / GRAPH_TABLE)
in PostgreSQL 19. CREATE PROPERTY GRAPH and fixed-depth GRAPH_TABLE
pattern matching both work well and are a genuine readability win over
the equivalent self-joins. One thing stood out enough that I wanted to
ask rather than just assume it's unfinished: quantified
(variable-length) path patterns don't appear to be implemented at all.

Setup: a simple self-referencing property graph over an employee/manager
table.

    CREATE PROPERTY GRAPH city_org_graph
        VERTEX TABLES ( city_org KEY (id) LABEL employee PROPERTIES ALL
COLUMNS )
        EDGE TABLES (
            city_org AS reports_to
                KEY (id)
                SOURCE KEY (id) REFERENCES city_org (id)
                DESTINATION KEY (manager_id) REFERENCES city_org (id)
                LABEL reports_to
                NO PROPERTIES
        );

I tried both forms the standard defines for repeating a path: a
quantifier directly on an edge, and a quantified nested group. I was
trying to walk from an employee up to the root of the org chart at
unknown depth:

    MATCH (a IS employee WHERE a.name = 'Leo Park') -[IS
reports_to]->{1,10} (root IS employee)
    -- ERROR:  element pattern quantifier is not supported

    MATCH (a IS employee WHERE a.name = 'Leo Park') (-[IS
reports_to]->(IS employee)){1,10} (root IS employee)
    -- ERROR:  unsupported element pattern kind: "nested path pattern"

Both are parsed far enough to be recognized and then explicitly
rejected, rather than a plain syntax error, so this doesn't look like a
mistake on my end — it reads like the feature genuinely isn't there yet.
I retested identically on a fresh PostgreSQL 18.6-based rebuild just to
rule out anything environment-specific, and separately re-ran the same
two queries against PG19 beta3 after it was tagged; the errors are
byte-for-byte identical to what PG19 beta2 produced.

A few questions, if anyone can point me in the right direction:

1. Is quantified path pattern support intentionally deferred past 19, or
is there a patch/commitfest entry already in flight that I should be
watching?
2. If it's deferred, is there a tracking thread or open item I could
link to, so the book can point readers at the right place instead of
just saying "not yet"?
3. Is there a recommended workaround inside SQL/PGQ itself for
unbounded-depth traversal, or is a recursive CTE still the correct
answer for that case in 19?

Happy to share the full reproduction (it's a self-contained example, no
extensions, just core PG19) if that's useful. Thanks for all the work
getting SQL/PGQ this far — the fixed-depth pattern matching and
undirected edge support are genuinely nice additions.

Thanks,
Chris

[1] https://chrislee35.github.io/postgresql-beyond-relational-lab-book/