The behavior you describe should not occur.  Adding the files to the branch and re-merging is a correct procedure.  
Git doesn't know or care that you're "re-introducing" code; to git files are added, and that itself is a change.  So the fact that files with the same name and content were earlier deleted, or that they hadn't been otherwise modified on the branch, or anything else... doesn't matter.  You're introducing a whole bunch of concepts that don't really exist, and complicating your view of what git does.
You had
O --- x --- x --- x <--(master)
 \
  A --- B --- C --- D <--(branch)
and maybe A deleted foo/*.  You merged
O --- x -- x --- x -- M <--(master)
 \                   /
  A --- B --- C --- D <--(branch)
and now the deletion of foo/* was carried into M.  To fix this you add a commit to branch
O --- x -- x --- x -- M <--(master)
 \                   /
  A --- B --- C --- D --- E <--(branch)
and E creates files at foo/*.  If you merge this to master:
O --- x -- x --- x -- M --- M2 <--(master)
 \                   /     /
  A --- B --- C --- D --- E <--(branch)
the merge base is D.  Only D, E, and M are examined to produce M2.  Because M doesn't do anything at foo/*, while E creates files at foo/*, M2 will get the files.  The history before D doesn't matter.
This is documented behavior which has worked in numerous tests for countless users, so I would advise that you re-check your work and make sure you re-added and merged in the way you describe.