If the player's inventory contains an item with a block tag in its can_place_on or can_destroy fields, and the /reload command is run (even if only the vanilla datapack is present), any subsequent copy of that item given to the player will be treated as different and be unable to stack with the original item, despite the two appearing identical from a data perspective.
Once the player's inventory is updated (by opening a container, etc.) the two items become stackable again.
Steps to reproduce (25w04a+):
/give @s stone[can_place_on=[{blocks:"#minecraft:dirt"}]]/reloadAgain,
/give @s stone[can_place_on=[{blocks:"#minecraft:dirt"}]]
Note the items do not enter the same inventory slot and cannot stack, despite no changes being made to the command.
For flavor,
/data get entity @s Inventoryand compare the two items' data - the data will appear identical but the stacks still will not combine.
Open a chest, shift-click both items into it; now they stack.
Attachments
Comments 2
Can confirm. Minecraft version: 1.21.3
You can make a datapack with nothing inside it besides 1 single loottable giving you a stone block with a can_place_on tag with for example #minecraft:all_hanging_signs.
Now, while in adventure mode, give that loottable to yourself in game with a /loot give, and notice how all works as expected.
Type /reload and give yourself that loottable again- notice how that new loot item doesn't stack with the previous item.
Also:
clear your inventory, enter adventure mode.
give yourself that loottable from the previous example.
reload.
now just open your inventory and start clicking the item around into different inventory or hotbar slots, you will notice how it becomes a "ghost item" quite frequently by flickering or making a duplicate of itself that disappears once you interact with it.
This is very broken, and quite annoying if you use any block tags combined with can_place_on in your datapacks.
Can confirm