A successful entitydata, with white text output, will duplicate the villager inventory – after the text is displayed. The white displayed text is the old value, before the duplication. To see the duplication, you have to use another entitydata command. It's best to use a failed one, with red text, as red text doesn't cause further duplication.
Summon a Villager:
/summon Villager
Give him 3 seeds:
/replaceitem entity @e[type=Villager,c=1] slot.villager.0 wheat_seeds 3
Check his inventory with a failed, red entitydata command. Notice Count:3b (near the end of the NBT) for the 3 seeds:
/entitydata @e[type=Villager,c=1] {}
Do it again, and notice Count:3b again. Nothing has changed yet.
/entitydata @e[type=Villager,c=1] {}
Now use entitydata to change his name. The white text will display Count:3b, but it's lying!
/entitydata @e[type=Villager,c=1] {CustomName:TestGuy}
Use a failed, red command to check his inventory. It shows Count:6b.
/entitydata @e[type=Villager,c=1] {}
Do it again. Still Count:6b.
/entitydata @e[type=Villager,c=1] {}
Use another successful entitydata. It will display Count:6b, but it's lying!
/entitydata @e[type=Villager,c=1] {Glowing:true}
Use a failed, red command to check his inventory. It shows Count:12b.
/entitydata @e[type=Villager,c=1] {}
Do it again. Still Count:12b.
/entitydata @e[type=Villager,c=1] {}
Related issues
is duplicated by
Comments


Editing nbt tags during the life time of an entity is not supported; and issues regarding that won't be fixed.

I don't understand the technical phrasing. Is that just a way of saying that the entitydata command is only partially supported?
It's not a specific tag that doesn't work. Any use of entitydata on a Villager will duplicate the inventory.

Enditing nbt tags = /entitydata and /blockdata.
Bugs caused by them won't be fixed.

They fixed an /entitydata bug in MC-95738 similar to this one. Any change, even to CustomName, had side-effects. In that case, it reset the Slime's hp. In this case, it duplicates the villager's inventory.
I can't tell if you have special knowledge of exactly when Mojang cares about /entitydata bugs and when they don't, or if you're over-interpreting Serge's comment from 2014. At least in MC-95738, they did care about this type of bug. But perhaps they'd feel villagers duplicating their food isn't as important as slimes resetting their hp.

Yes, I'm refering to @unknown's comment; and we've been instructed to resolve any tickets regarding editing nbt tags during an entity's lifetime. (Not sure why they fixed slimes then.)

It's been 4 years. This is still in the game and can easily be fixed by making fromTag()
& createTag()
in SimpleContainers
use setItem()
instead of addItem()
Or just making a new class that acts exactly like PlayerEnderChestContainer
which already does this xD
This is a simple fix and should not have been too invalid, to begin with!
Mojang Mappings where used for the code analysis
This would be the same fix as MC-191011
Piglins and Villagers both get this issue inside of readAdditionalSaveData()
for the this.inventory
SimpleContainers
Can Confirm both for 1.17.1

Confirmed in 1.18.1 and 1.18.2-pre3. If editing NBT tags during the lifetime of an entity is not supported, then the /data ... entity
command should not exist. If editing these specific NBT tags is not supported, the command should give an error and refuse to modify them.
"Unsupported" does not mean "disallowed," but rather "no guarantees"

I made a command that modifies a piglin's angry_at memory. As this command is repeated every tick, the piglin's inventory quickly fills up. I suppose I'll need to use the silly snowball method to make the mob angry at a specific mob without this bug happening. Hopefully this gets fixed, even though the report is marked invalid.

While fixing MC-253076
They actually went through and fixed the others!
Fixed in: 22w42a

There isn't really "went through". The bugs are true duplicates, and if was fixed in 2017 none of the others would have happened. I only reported this to help. I thought it was selfish to understand a bug and say nothing, so I said something.
Mojang has given mods bad policy that doesn't distinguish "Some tags won't work if you try to change them," from "Bugs don't matter at all if they involve data commands." These are two very different things. (The bug is not about a tag.) Both this and MC-95738 (and who-knows what else) were fixed when devs saw them, but the policy tells mods not to let devs see them. There must be a better way to do this. Or with luck there are no more bugs like this...

Except that all these had the issue in different parts of the code (arrow class, villager class, allay class, etc.), thus each requiring their own fix.
Also, that policy is no longer in effect, but old reports were not allowed to get reopened by the mods.
The bug exists in 1.8 and 1.11 as well. I can't find a way to edit this into Affected Versions.