Here's a suggested scheme of the implementation of this feature.

Let Q be an n-way join query of tables such that some of tables belong to the engines that can execute join operations SELECT ... FROM t[0],...,t[n] WHERE P(t[0],...,t[n]).
Consider a possible join order t[i[0]],...,t[i[n]] and let T[0],...T[k] be partitioning of this join order such that any
partition contains only tables from the same engine and no neighbors has tables from the same engine.
Let's also assume that for any two neighbors only one belongs to the engine that can execute join by its own means while the other executes joins by MariaDB SQL processor. Let's assume that T[1] belongs to the engine that can execute join by its own means. Then any odd partition also belongs to such an engine while joins of any even partition are executed by SQL processor.
Let partition T[j] consists of tables t[j][0],...t[j][lj]
It's obvious that query Q is equivalent to the following query

SELECT ... FROM

   (SELECT (...

      (SELECT ...FROM

          (SELECT ... FROM t[0][0],...,t[0][l0]) AS dt[1],

          t[1][0],...,t[1][l1]) AS dt[2] ...) AS dtk, t[k][0],...,t[k][lk]

 WHERE P(t[0],...,t[n]).

In this query first we define a derived table dt[1] that joins tables from T[0]. Then we define the derived table dt[2] that joins dt[1] and tables from T[1]. The derived table dt[j+1] joins the derived table dt[j] with tables from T[j].

Another scheme just encapsulate tables from odd partitions into derived tables and pushes conditions
into these derived tables

SELECT ... FROM

...

(SELECT ... FROM t[k][0],...,t[k][lk] WHERE P(t[k][0],...,t[k][lk])) as dtk

...

WHERE P(t[0],...,t[n])

Here P(t[k][0],...,t[k][lk])) is the condition over t[k][0],...,t[k][lk] that can be extracted from P(t[0],...,t[n]).

With this scheme we rather push into the engine SELECTs that specify derived tables.
This well fits into the scheme how SELECT queries are handled by ColumnStore.

Let's call a derived table External Derived Table (EDT) if it is specified by a SELECT over tables belonging to the same external database engine capable to execute SQL operations.
If an EDT is used in a query we always consider it as a materialized derived table whose materialization is performed by an external engine.

Some observations
1. Rows of a EDT for ColumnStore engine could be produced in the same way as the result set for a select query.
2. To process EDT the server needs a special function to fill the EDT that would use the iterator function over the rows of EDT
3. The optimizer has to know the cardinality of EDT. This cardinality either calculated by the external engine or is calculated by the optimizer itself employing the statistical data on the tables and columns referenced in the specification of EDT.

I spinned off MDEV-17096 "Pushdown of derived tables to storage engines".
This is the first step to resolve of the problem of pushing joins into storage engines.
This is probably the only task that realistically can be done within 10.4.