AjaxGb

Confirmed in 26.2, and for 26.3 snapshot 10 with the renamed "shade_direction_override": "up" property.

In addition to item frames, this also affects block displays. You can easily see this without any resource pack at all by spawning a redstone torch block display:

# 26.2
/summon minecraft:block_display ~ ~ ~ {block_state:{Name:"redstone_torch"}}
# 26.3
/summon minecraft:block_display ~ ~ ~ {block_state:{id:"redstone_torch"}}

A fix would look something like:

   public static boolean wouldSuriveAt(final Level level, final AABB boundingBox) {
      AABB anchorBox = new AABB(
         boundingBox.minX, boundingBox.minY - 0.015625, boundingBox.minZ, Math.nextDown(boundingBox.maxX), boundingBox.minY, Math.nextDown(boundingBox.maxZ)
      );
      AABB blockCheckBox = anchorBox.setMinY(anchorBox.minY - MAX_BLOCK_SHAPE_HEIGHT_ABOVE_FULL_BLOCK);
      
      for (BlockPos blockPos : BlockPos.betweenClosed(blockCheckBox)) {
         BlockState blockState = level.getBlockState(blockPos);
         VoxelShape shape = blockState.getShape(level, blockPos);
         if (!shape.isEmpty() && shape.bounds().move(blockPos).intersects(anchorBox)) {
            return true;
         }
      }

      return false;
   }

(I release all rights to this code modification)

*Cushion.wouldSuriveAt()

Code analysis: this is because Cusion.wouldSuriveAt() [sic] only checks for collisions with blocks that are at most 1/64 blocks below itself:

   public static boolean wouldSuriveAt(final Level level, final AABB boundingBox) {
      AABB anchorBox = new AABB(
         boundingBox.minX, boundingBox.minY - 0.015625, boundingBox.minZ, Math.nextDown(boundingBox.maxX), boundingBox.minY, Math.nextDown(boundingBox.maxZ)
      );

      for (BlockPos blockPos : BlockPos.betweenClosed(anchorBox)) {
         BlockState blockState = level.getBlockState(blockPos);
         VoxelShape shape = blockState.getShape(level, blockPos);
         if (!shape.isEmpty() && shape.bounds().move(blockPos).intersects(anchorBox)) {
            return true;
         }
      }

      return false;
   }

This means that it never checks collisions with the lectern block when placed on the highest edge, since the block position is too far away. If it did, it would see that the shape intersects. The game should scan at least 2 pixels further down for blocks, since the interaction shape of lecterns is 18 pixels tall.

Can confirm in 24w06a.

@@unknown Eight-year-old comment, but it seems to me that the "correct" solution would be to do attribute application in two passes. First, go over all the slots as you described, but only process item removals. Then go over all the slots a second time and process all the item additions.

Can confirm in 1.17

Did some digging on this. Turns out Striders set their NoGravity flag to true when they're in lava and to false when they aren't; that's how they float. Certain things can make the flag get stuck on true. A consistent and easy one is just saving and quitting while the Strider is standing in lava. After you reopen the world, the Strider is stuck floating at their current height forever. The flag being stuck like this also prevents them from walking up blocks, which they can normally do.

This also relates to MC-176203, as the NoGravity flag prevents levitation. Striders probably shouldn't be using that flag; it's mostly intended for command use only.

@violine1101 I actually don't think that's a duplicate. That bug is about how, when the lodestone is broken, the compass is still a Lodestone Compass, just a Lodestone Compass that points to nothing. This bug is about how, when the lodestone is broken, compasses in containers won't notice at all, and will continue to point to the lodestone's old location until they are placed back into the player's inventory.

Confirmed for both 1.15.2 and 20w07a.

 I was unable to reproduce in 1.15.2. Seems to be resolved.

Confirmed for 1.14.4 and 19w41a.

I suspect that this is happening because villagers have a much smaller hitbox while sleeping.

Confirmed for 19w04b.

Confirmed for 18w32a, with the upper limit of distance= in place of r=. Setting only the lower limit has no effect, so

distance=1000000..

will not trigger the bug, but any of

distance=1000000
distance=..1000000

will.

And for 18w32a.

Confirmed for 1.13.

@Cody
It's a block tag. It can be set with datapacks.

Confirmed for 1.12.2 and 1.13-pre5.

Confirmed for 18w16a.

Confirmed for 18w10d.