Here's the seed for another partial example: 1316773048766186309
The village at -1448, , 40 has one large house structure completely underground in a cave beneath several of the other structures.
Created in 1.20.60 on iPadOS
To clarify, it's not just swimming underwater that's affected. Crossing water (as in walking on the surface of water) is also affected, and the player now sinks instead of staying on the surface. 1.19.81, iPadOS, iOS.
Still apparent in v1.19.70, on iPad (8th generation), iPadOS 16.3.1
I attempted to replicate the behavior, but was unable to. Near as I can tell, though, I was at Y=-60, standing on bedrock, I respawned at the same X/Z coordinates, and that there were solid blocks between where I started at Y=-60 and where I ended at Y=-23.
Shannon Young points out an interesting separate-but-related potential unintended consequence of the change in despawn rules: villagers you have not interacted with will despawn when you travel more than 32 blocks from the village. I was wondering why, each time I returned to a village, I would find vast numbers of baby villagers, when I had not altered the number of beds, and a raid could obviously not have happened while I was that far away. A few interesting consequences might be worth watching:
+what happens to the user reputation when this happens? Does it increase at a vast rate because of the introduce-a-new-villager reward, despite the user having done nothing except leave and return?
+what happens if the farmers of the villagers are the ones that despawn? Does the lack of farmers, and thus food, mean that villagers can't breed to replace the despawned villagers? This could be an inadvertent way to quickly turn a populated village into an abandoned village.
+what happens if the user visits and departs a village several times in quick succession? Does a group of villagers despawn each time, again providing an inadvertent way to turn a populated village into an abandoned village?
I know this issue of entities disappearing along border chunks is a knotty problem, with years of effort trying to isolate and resolve it, so if this villager despawn issue should be a separate report, let me know and I'll repost this as a separate item.
I've noticed that quitting the game and reentering resolves the problem; the Iron Golem does not stay focused on killing the player when she returns. iOS v1.14.1 (and several versions previous to that)
I've noticed this as well, though only for Iron Golems that I have spawned. Those Iron Golems will protect villagers from threats (player and non-player) but, as soon as there is no longer a threat, appear to get bored and wander off aimlessly. Naturally-spawned Iron Golems stay in the village as expected.
iOS v1.14.1 (and previously noticed in v1.14.0)
I've seen this, too, under iOS. If the horse is leashed, it doesn't despawn, but dismounting without leashing will result in it despawning in what seems like a very short time; I haven't been able to time it yet, but it seems like less than one Minecraft day. The worst part, especially in early game play, is losing the saddle...
Seeing similar behavior in 1.13.0 on iOS 12.4.1. First noticed it as milk bucket emptying when killing the cow just milked. Thought that might be intended behavior so next milked a cow and then tried to save the milk bucket in a chest, and discovered that any interaction with the full milk bucket results in an empty bucket. Not sure how killing the cow (or engaging in any other melee combat) triggers it, but it's very repeatable.
The real impact is that there's no getting rid of the Bad Omen status effect while this bug endures!
I'll confirm that they are spawning under water as of 1.6.2 on iOS.
Seems resolved in 1.5. Arrows that hit make normal hit noise and cause damage, and arrows that miss cannot be collected.
Update: the creeper behavior is far less predictable than I first observed, and it can sometimes climb up one block, but other times gets stuck by normally navigable objects like water, trees, shrubs, etc. I’ll be curious to see if anyone else can help spot a pattern...
Seems resolved in 1.5, though now parrot behavior is vastly different (for the worse). Parrots now dismount shoulder when stepping down even just one block, and no longer protect player from fall damage when jumping more than three blocks...
Seeing this in 1.5 for iOS regular games. Game host doesn’t seem to be affected, but all other players are. Haven’t observed it under normal game quitting, but happens every time host quits (or connection is lost or game crashes) before other players.
Still observed in 1.5 (iOS).
Although I understand there were no code changes in 1.4.3, I can no longer reproduce a situation where I can collect missed arrows fired by skeletons. The rest of the behavior seems as described, with only about one in five skeleton arrows that hit the player causing any damage, and no discernible difference between the trajectory of arrows that cause damage and those that don't.
I see a variant of this; whenever the player walks too close to lava (distance undefined, but roughly less than a quarter block) with a parrot on its shoulder, the parrot catches on fire, dismounts the shoulder, burns, and dies. It's so consistent that I wonder whether it might be a feature of parrots: highly flammable; keep away from lava? Repeatable up through 1.4.3 under iOS.
Confirmed in 1.4.2 for iOS
@Austin Stratton, others seem to be seeing a different effect than you are. I'm finding the ability to farm arrows endlessly by letting a skeleton shoot but not hit me, then moving to where the arrow landed and collecting it. My inventory of arrows increases each time I do. As you note this is definitely different behavior than we're previously accustomed to. If, as you state, there was never a change to allow players to pick up missed arrows, then this is a bug, and properly reported here. And that bug could cause the appearance of players "catching" arrows that narrowly miss them. It's also possible that there are other factors at play, including a bit of weirdness involving hit boxes and certain intercept angles, which could cause some arrows (those that just happen to align with the suspect intercept angle) to hit the false hit box instead of the player's hit box, thus becoming available to collect, while the rest of the arrows hit the player and cause damage as usual. I think there's a lot going on here, and we may each only be seeing part of it.
Change is hard, but this change breaks touch navigation. The biggest complaint is that the gaps between the navigation arrows don't seem to be part of the new D-pad interface... if you start moving forward by touching the upper arrow and then decide to move right by dragging your finger to the upper right arrow, the moment your finger leaves the upper arrow, the upper right arrow disappears from the D-pad and you start interacting with whatever is behind the D-pad (ex: you start digging instead of moving). That behavior is annoying when just moving around but becomes detrimental when involved with complex movement such as is required during melee combat.