It seems that you don't understand how tables are related. There is only ONE relationship between tbl1 and tbl2 and it is accomplished by placing the PK of tbl1 into a field we refer to as the FK in tbl2. Just because two tables contain duplicate data doesn't mean they are related. What it means is that your schema is not properly normalized. Each piece of data is defined in one and only one table. The reason you don't need to duplicate the customer name in the order table is because the order table should contain a FK that contains the CustomerID and that points to a unique customer record where you can obtain the customer's name whenever you need it.
Newcomers don't intuitively understand this and frequently make the mistake of duplicating data because they don't know any other solution.
When the majority of "child" records will have ValueX in a particular field but some will differ, then the mistake is what you are currently doing. If the default is general and no matter what the parent is, the default is always ValueX, then, make that the default at the table level. If the default is somehow tied to the parent record, then add a field to the parent record to hold "ValueX". Then in the BeforeInsert event of the child record, copy the value from the parent record to the child record. If you later want to change the default in the parent record to ValueZ, that doesn't affect any child records. New records get "ValueZ" in the BeforeInsert event. Existing records don't change. If you want to change existing records, you need to run an update query that changes "ValueX" to "ValueZ" for all child records with the FK equal to the parent record. In all other cases, the value changes manually one record at a time by the user.
If you want to filter the subform, add an unbound combo that selects the list of values. When you choose "ValueZ" from the combo, only the "ValueZ" records will show in the subform. Is that what you are looking for?
If you would be specific about what data we are talking about and the business process you are modelling, we can probably give better advice. Currently, I question the logic of what you are doing because I can't envision the business process you are modelling. Labeling things fld1 and fld2 is absolutely useless.