For me, multi-table workflows typically come with the needs of schema evolution as well as preserving history/changesets for FAIR workflows.
There are lots of ways to deal with schema evolution, such as no schema (schema-less) systems, as well as schema-base systems like RDBMS & OLAP systems where some now support schema evolution.
If the need is to keep snapshots, history, ability to undo or rollback history, then additional complexity comes into play as well at scale with multi-table workflows.
2 recent technologies that build upon lessons learned from the past 6 years that I have looked at over the COVID crisis and really like are
Apache Iceberg's Table Evolution supporting schema evolution that even includes nested structures. And since history and undo capabilities are needed even through table merges and change isolation, then
Project Nessie and it's Git-like branching, tagging etc. operations could be incorporated.
If you step back and look at OpenRefine's modeling, it sort of mimics both of those together. But where both of those technologies allow for massive scaling.
Many of our users won't need such scale, however, the features offered are closely aligned with OpenRefine's mission of transforming data, schema, etc. through exploratory analysis and series of operations that often need to be preserved and shared to support FAIR workflows.