Wow, this sounds strikingly familiar to another conversation I just had with Jody Hesch... funny how these topics weave throughout your day 
I would be interested to get an opinion/feedback from Lars Breddeman since he is the king of small tricks to get better performance.
What I found to be true, is just as Jody said - for a filter/variable to truly be pushed down, it needs to be clearly mapped all the way from the source and NOT derived from a join AFTER the union. In the case of the AN as a source, the same should be true - just make sure you are mapping the columns to the unions consistently.
For example, consider two scenarios, each will require a mandatory variable on the column "OWNER" to ensure smaller datasets.
Case #1 - two tables are unioned and then joined to another table to derive OWNER.
In the Vizplan, we can see that even though we specified something in the where clause/variable, we are getting a lot of records (~5million) at the lowest level, and the filter kicks in after the join. Execution is about 1.1s. This shows me that the ENTIRE union needs to be generated for the filter on the joined column OWNER to be properly evaluated.
Case #2 - two tables are joined THEN unioned, bringing the desired filter column OWNER through the union and into the result set.
In the Vizplan, we can see that at the lowest level the filter is being pushed down, only 9 records are returned after the joins are evaluated. Execution is about 100ms, 10x faster than the previous example. Extrapolated over a large dataset, this would be a much more significant number.
Happy HANA,
Justin