Please read SkylinerW's comment with code analysis

5. The entity has its UUID set to the copied UUID
6. The new merged NBT data is applied to the entity (which then overwrites the UUID)
Step 5 needs to happen after step 6, or the tags need to be stripped explicitly.

—

In 1.8.x you can not change an entity's UUID by using e.g. this command:

/entitydata @e[type=Zombie,r=1] {UUIDLeast:3L,UUIDMost:3L}

You will get a message in red saying "The data tag did not change."

Also, in 1.8.9 you can accidentially summon 2 entities with the same UUID which can cause harm to your world.
This is not possible in 1.9 snapshots, incl. pre-4 (but I found a way to do that).

In 1.9 pre4 you can change an entity's UUID though which results in "unresponsiveness" of said entity for the duration of your session:
"The entity can not be found."

If you relog, the entity can be found again.

Steps to reproduce

1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1}

2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L}
>>> Data tag successfully changes (white text, you can see the changed UUID)

3. /entitydata @e[type=Zombie,r=2] {}
>>> Results in: "That entity cannot be found"

4. /tp @e[type=Zombie,r=2] @p
>>> "That entity cannot be found"

I don't know if it is intended that one can change an entity's UUID at all via entitydata in 1.9 as you couldn't in 1.8, but if it is intended, there's at least said bug that you cannot find such an entity afterwards for the duration of your session.

Due to this bug you can apparently successfully get infinitely many times the same UUID though, which should definitely not be possible.

Steps to reproduce

1. /summon Zombie ~ ~1 ~ {UUIDLeast:33L,UUIDMost:33L,NoAI:1}

2. /entitydata @e[type=Zombie,r=2] {UUIDLeast:3L,UUIDMost:3L}
>>> UUID gets successfully changed, but entity cannot be found for this session.
Although the Zombie's UUID got changed into UUIDLeast:3,UUIDMost:3, it is NOT possible to summon a Zombie with UUIDLeast:33,UUIDMost:33!
It's as if the entity got at the same time both UUIDs.

3. /summon Zombie ~ ~1 ~ {UUIDLeast:3L,UUIDMost:3L,NoAI:1}
>>> You can summon a Zombie with UUIDLeast:3,UUIDMost:3 though although it shouldn't be possible as the other Zombie already got that UUID after you changed it via /entitydata.

4. Run:
/entitydata @e[type=Zombie,r=2] {}

5. If you relog again, then one of those Zombies will automatically be gone, but the UUID output will be 2 times, although only 1 Zombie is (visibly) left.

Now comes the oddity:
The Zombie that is gone (at least not visible), the one whose entitydata got changed, still outputs its data with that changed UUID (output will be only once).

I run

 
/entitydata @e[type=Zombie,r=1] {} 

right next to where the Zombie was before (but is not anymore upon relog), and the other, visible, Zombie can't be the reason for the output.

If I run the same at the "leftover", visible, Zombie, it will output its data as well with the exact UUID (output will be only once).

If I run the same with r=2 while standing in the middle between the visible and the "ghost" Zombie, it will output the data with the same UUID twice, as if both Zombies would still be there.

This happens every time, also if I relog, so I guess the world is now corrupted?

You can keep changing the UUID via entitydata as you please, which results in more and more outputs of the same UUID, from those "ghosts".

Edit:
After you did those steps above, if you run

/entitydata @e[type=Zombie] {}

without any radius, then it will output the data only once.

If you use r=1 at the "ghost" Zombie position or the visible Zombie, it will output each once.
If you run r=2 between them, it will output twice.

^{Sorry for the frequent changes, my cat ran over my keyboard and deleted text, saw it afterwards}

More info https://bugs.mojang.com/browse/MC-98244?focusedCommentId=290391&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-290391