I see, that's for sure. That's what every system does in one way or another. Both of the papers I have listed there describe different ways to do it: the Graphflow paper (and Kuzu) currently does this inside their dynamic programming-based join order optimizer. Umbra does it after a good join order is picked.
Indeed pretty much everything is doable in every DBMS, graph or relational, simply because all DBMSs from enough distance are very similar in terms of their core features: a high-level query language that compiles to relational operators, support for transactions, a recovery mechanism etc. What differentiates them (aside from the data models and specific query language syntax they expose to users) are what type of applications they choose to provide optimizations for. Graph DBMSs immediately come into mind for wcoj algorithms because the applications they support frequently contain cyclic many-to-many join queries, which is the workloads wcojs can provide performance benefits. RDBMS, OLAP or OLTP don't assume their application workloads contain such queries. That is why every work done on wcojs so-far has used "graph patterns and workloads" in their evalution, not something like TPC-C or TPC-H.
