The query in /fnJoin/tpch09.sql produces a circular graph for JOIN operation in the subquery. This happens when MDB runs optimize_cond(). Here is the COND item in optimize_inner() before optimize_cond(), right after it and after optimize_stage2().

(gdb) p dbug_print_item(conds)
$3 = 0x563261f559a0 <dbug_item_print_buf> "supplier.s_suppkey = lineitem.l_suppkey and partsupp.ps_suppkey = lineitem.l_suppkey and partsupp.ps_partkey = lineitem.l_partkey and hex(part.p_partkey) = hex(lineitem.l_partkey) and orders.o_orderkey = lineitem.l_orderkey and supplier.s_nationkey = nation.n_nationkey"

$5 = 0x5600736ee9a0 <dbug_item_print_buf> "hex(part.p_partkey) = hex(lineitem.l_partkey) and multiple equal(supplier.s_suppkey, lineitem.l_suppkey, partsupp.ps_suppkey) and multiple equal(partsupp.ps_partkey, lineitem.l_partkey) and multiple equal(orders.o_orderkey, lineitem.l_orderkey) and multiple equal(supplier.s_nationkey, nation.n_nationkey)"

$8 = 0x5600736ee9a0 <dbug_item_print_buf> "lineitem.l_suppkey = supplier.s_suppkey and partsupp.ps_suppkey = supplier.s_suppkey and partsupp.ps_partkey = lineitem.l_partkey and orders.o_orderkey = lineitem.l_orderkey and nation.n_nationkey = supplier.s_nationkey and hex(part.p_partkey) = hex(lineitem.l_partkey)"

The latter case already contains a cycle in the JOIN keys graph.
The proper solution is to both remove STP check and force MDB to return the same set of conditions in cases like given.