I think these are good ideas, yet I have a couple of points to make.
a) Filters don't need a from clause. Or do you want to be able to filter by something which is not an element? In that case you would need a from and a where clause and make sure that part of the where clause is the join with the primary table.
b) Wouldn't it be better instead of saying "from" and "where" clause to make sure an element can be picked up, to have a general "condition" element which is a list of {primary_key table_name join_key} and then use that named condition on all elements that need it? This way you do not have to add the select, from, and where clause to each element and make sure that you are not adding the clause twice just because you have two elements that have that clause in them.
c) If you go with conditions you have the additional benefit that you could allow for editing a row as well, as you could get the list of elements and from which table they are from (due to the condition) and then create an ad_form which lets you edit one row in your table across multiple phyiscal tables. Obviously that might have other consequences, so we might actually think instead of using primary_key and table_name to use object_type, so we could join up any object_type into the current table and use attributes / elements from that object_type.
My main concern is that though the clauses give you flexibility I would prefer to have something more formalized so it is easier to reuse in different environments where the from clause might not be enough. Thats why I would use conditions and object type, but probably you thought about that as well and dropped that idea for a reason.
