James Wall

Just found what I think might be a related bug. When attempting to use /data set entity, to apply the value {id:leather_horse_armor,Count:1} to ArmorItems[2] on a horse, it fails.
Also failed when I tried to set the value of ArmorItems to a 4-item array with the leather armor at index 2, it still failed.
So where we're at now, the data tag fails to modify ArmorItems, and Attributes, but succeeds with the Villager's Orders.Recipes array. My first thought was it was simply failing on all arrays but since I can mess with Orders.Recipes that doesn't seem to be the case. At this point, it seems that any array object at the root level is failing to be modified properly, but arrays further down the tree are working more or less OK? Except Modifiers, but that's encased in an array at the root level itself, so I think the problem is happening before the NBT data command even reaches the Modifiers item.
All of this being said, I can set the value of the ArmorItem field, not the ArmorItems array, and apply the horse armor just fine. So once again I'm led to believe somehow the NBT DataCommands class has some kind of issue with arrays.

Just ran across this bug when playing with a buddy on 1.15.2
We found that not only is deleting impossible, but when I try to merge the array it simply adds the new objects into the array, and we found that when you try to use "data set" on an individual field in the modifier object, such as UUIDLeast or UUIDMost, you end up duplicating the entire modifier, one with the old data and one with the new data. We tested this with villagers, horses, and pigs, and had no luck.
We couldn't delete the modifier. We couldn't "set" the value of the array to empty. We couldn't delete the Modifiers array completely. We couldn't delete the attribute object, and we couldn't empty the Attributes array. It seems once there's a value in the Modifiers array, it's permanent and locks up any attempt to remove its parent objects as well. We were able to modify individual field values within the Attribute that had the modifier but that's about it.

Issue still present in 1.15.2 with bees and end rods specifically. What's worse is that the bees seem to actively pathfind into end rods; i.e. if there's a wall of end rods they seem to preferentially fly into the rods rather than between the gaps. My entire base right now is lit up with end rods and every single bee in the area is stuck to one of them until I go and break it, at which point they go get themselves stuck on the next one.
Interestingly enough the bees also seem to fail to pathfind out of the endrod block once they're in it; for example if you're holding a flower and walk such that the bee wants to track you away from the end rod itself, it'll just never move. On what may or may not be a related note, bees also completely fail to pathfind away from lava.

Currently playing on a 1.15.1 server and this behavior still exists. If I'm not mistaken, the back face of a piston (or the top, as shown in the pictures) is always a solid surface, yes? so hypothetically speaking something placed on top should not pop off. More importantly it seems to only break off when the piston retracts, and not when it extends initially. My first thought was that the piston body was being turned into a non-solid block entirely, and that the lever simply hadn't received a BUD that would trigger it to break off of the non-solid block it was attached to, but then I did some testing to manually trigger a block update next to the lever-occupied block, and I can't seem to force the lever to pop off that way. It only ever gets broken while the piston is retracting.
Additionally, while doing that testing I noticed that during the piston's retraction sequence, if the player is standing on top of the back face of the piston where the lever/button/redstonedust/etc is popping off, the player actually receives a slight upwards bump. I also was able to reproduce this with an armor stand (See attached screenshot of the exact moment the armor stand is bumped upwards).

This also works with shulkers (the actual mob from the End).

The upshot of this is that I think for some reason the block the piston body occupies, when it starts to retract, is actually being pushed upwards just a tiny bit before it gets removed and replaced with a "retracted piston" block during the retraction sequence. It also seems to dislodge item frames from the back face of the piston. (edit: buttons, levers, redstone dust et al, aren't supposed to be movable via pistons IIRC is why this is important).

I hope all of this has helped.

My witch hut freshly generated in 1.8.1-pre2 is having a similar issue to this due to it generating higher than normal. Unlike the issue above however, the spawning box appears to have been cut down in size as it ranges from y66-y71 instead of y64-y70, meaning my farm can only have two spawning floors.

Not sure if this relates too closely to the issue above, but I'm new to the tracker and do not want to start off by posting a potentially duplicate issue. I apologise if this does not belong here.