Rules Add an item to a List overwrites existing data
Your rule in your question seems to have "a few" (not just one) issues that need to be addressed. So I'll build a list of these issues here (and will add more of them later on if needed) ...

Issue 1:

Think about this: "Why have that 1st Rules action (a loop), if inside that loop there is nothing happening (as per the "DO" : [] in it)?". Either the loop is just redundant, or there is some Rules action(s) still missing inside that loop (more research needed).

If it was me to decide, for now I'd delete that Rules Action. And if needed I'd restore it later on if I have a real reason to do so (i.e. if there is at least 1 Rules Action that I know I'd need, as part of that loop.

Issue 2:

At the core of your question, there is your "It is not to overwrite the terms already present in the field". The typical mistake in using Rules is that someone incorrectly uses a Rules Action like "Set a data value" (for a multi value field), and that will remove all existing values for that field. The correct way is to use a Rules Action "Add to list" (that will preserve existing values). Your last Rules Action does indeed perform a "Add to list" (as it should be done to achieve your goal), but what is suspicious in that Rules Action is that you use entity-fetched:0 ... That is a single value (as per the ...:0 part of it, but entity-fetched is a multi value list (it has to be like that, otherwise you wouldn't use that ...:0 part in it). But nowhere there is an indication why "the first value" in the multi value list  (stored in entity-fetched), is the actual value you want to add to your list.

Issue 3:

The rules event your using (= node_view), combined also with the Rules Condition, is rather suspicious also. For 2 reasons: (a) what if the event and/or condition are not satisfied (in that case none of the Rules actions get executed) and (b) if you're sure the Rules event and Rules condition is "always" satisfied, then you might be doing those Rules Actions over and over again.

Though there is possibly only reasons to do so in 1 specific scenario. I.e. for those situations related to your "I have a rule which picks up the primary email &amp; creates a taxonomy term from it" (let's call that your 1st rule, as compared to your 2nd rule shown in your question). It seems to me that your 2nd rule (as in your question) should be reworked like so:


Create a new Rules Component, with Rules Conditions and Rules Actions as you already have in your 2nd rule here.
Add and extra Rules Action to your 1st rule, which is simply/only to perform (= trigger the execution) of your 2nd rule.
In doing this redesign, you may have relevant / interesting data available in your 1st rule (like node id, user id, eMail id, term value, etc), which you can pass on to the Rules Component as a so called "Parameter" for that component.
And by having such parameters available in your Rules Component, you might possibly simplify the set of required Rules Actions needed to achieve your goal.
Don't forget to at least disable (or even delete) your current 2nd rule, after you reworked it to such Rules Component.


Possible other issues to be resolved

The above issues are, for now, only some suggestions to help you come closer to your goal. It's well possible (actually I'm about sure ...) you'll need other issues to be resolved also. But pretty sure the above issues will help you come closer. Btw, debugging is the art of taking away all possible reasons why it doesn't work ... as you want it to work.