In add_paths_to_joinrel(), the FDW specific hook GetForeignJoinPaths() is called. This hook if implemented should add ForeignPaths for pushed down joins. create_plan_recurse() calls create_scan_plan() on seeing these paths.
create_scan_plan() generates a list of clauses to be applied on scan from rel->baserestrictinfo and parameterization clauses. This list is passed to create_*scan_plan routine as scanclauses. This code is very specific for single relations scans. Now that we are using create_scan_plan() for creating plan for join relations, it needs some changes so that quals relevant to a join can be passed to create_foreignscan_plan().
Do we really need that? The relevant join quals are passed to GetForeignJoinPaths as extra->restrictlist, so I think we can get those quals during GetForeignPlan, by looking at the selected ForeignPath that is passed to that function as a parameter.
Right! You are suggesting that an FDW should just ignore scan_clauses for join relation and manage those by itself. That looks fine.
A related problem is in create_foreignscan_plan(), which sets ForeignScan::fsSystemCol if a system column is being used in the targetlist or quals. Right now it only checks rel->baserestrictinfo, which is NULL for a joinrel. Thus in case a system column appears in the joinclauses it will not be considered.
IIUC, we assume that such system columns are assumed to be contained in fdw_scan_tlist in the joinrel case.
From another mail thread [1] that you have started, I understood that fsSystemCol should not be set for a join relation, so the bug doesn't exist.