The variable federated_pushdown is not well documented:

https://mariadb.com/kb/en/about-federatedx/
https://mariadb.com/kb/en/server-system-variables/
http://lists.askmonty.org/pipermail/commits/2019-February/013402.html
https://jira.mariadb.org/browse/MDEV-23803

The only information found was this:

storage/federatedx/federatedx_pushdown.cc:

/*
This is a quick a dirty implemention of the derived_handler and select_handler
interfaces to be used to push select queries and the queries specifying
derived tables into FEDERATEDX engine.
The functions
create_federatedx_derived_handler and
create_federatedx_select_handler
that return the corresponding interfaces for pushdown capabilities do
not check a lot of things. In particular they do not check that the tables
of the pushed queries belong to the same foreign server.

The implementation is provided purely for testing purposes.
The pushdown capabilities are enabled by turning on the plugin system
variable federated_pushdown:
set global federated_pushdown=1;
*/

It looks like it works like this:

set global federated_pushdown=off;
select id, data from test_fed where id = 1;
-> Query on remote system: SELECT `id`, `data`, `ts` FROM `test` WHERE (`id` = 1)

set global federated_pushdown=on;
select id, data from test_fed where id = 1;
-> Query on remote system: select id, data from test_fed where id = 1

But this miserably failed with the following error (which is the/a bug):

ERROR 1030 (HY000): Got error 10000 "Unknown error 10000" from storage engine FEDERATED

Would be a cool feature to reduce traffic between the 2 systems, if it worked.