The Bug:
Buried treasure can create invalid block entities when generating in the location same as a block entity.
When a buried treasure chest is generated, it duplicates the block it replaces to the sides and on top if there is air. This is a problem because in some cases, this can cause spawners from mineshafts to be duplicated, however, the spawners are empty
Steps to Reproduce:
Go to a newly generated chunk, go to 9, ~, 9 (chunk coordinates).
Stand on the ground and summon some air below you using the command provided below.
/fill ~-2 ~-4 ~-2 ~2 ~4 ~2 air
Fly up a few blocks, but don't change your "x" or "z" coordinate.
Summon a cave spider spawner and then a buried treasure by using the commands provided below.
/execute positioned over world_surface run setblock ~ ~ ~ minecraft:spawner{SpawnData:{entity:{id:"minecraft:cave_spider"}}}
/place structure minecraft:buried_treasure ~ ~ ~
If the chest was placed under the spawner run the command provided below.
/execute positioned over world_surface run clone ~-2 ~-1 ~-2 ~2 ~-1 ~2 ~-2 ~-2 ~-2 replace move
Take note as to whether or not buried treasure can create invalid block entities when generating in the location same as a block entity.
Observed Behavior:
Observe that the buried treasure chest is surrounded on top and to the sides by empty spawners.
Expected Behavior:
If the said block is a block entity, the game should detect this and use a fallback block instead.
Linked issues
clones 1
Attachments
Comments 9

Can confirm.

I think the issue here is that burried treasure chests can spawn in (not under, in) a mineshaft tunnel in the first place; it would be safer to also make it copy the NBT data of the cloned block, but it shouldn't even spawn on that spot in the first place.

According to @unknown in this comment this is a separate bug:
— Working pig spawners spawn for a different reason, this is not the same bug, they spawn because when a buried tresure spawns, it hides itself by copying the blockstate without nbt data it replaced to it's sides that are air or water, so here i think the bug is that it only copies the blockstate and not the nbt data, and the spawners should be cave spider spawners
This might be why this was not fixed.

MC-163945 was originally about non-functional pig spawners that were created when two dungeons generated next to each other and the chest of one dungeon overlapped the spawner of the other dungeon. The bug about functional pig spawners being created by buried treasure overlapping a cave spider spawner (in a mineshaft) was later added to MC-163945, but apparently, it would have been better for a separate report to have been created instead.

Do we have any examples of this in 1.18+ due to big world generation changes? Seed provided in the description cannot be used to replicate the issue anymore.

The core issue still seems to exist as of 23w35a. To test, follow the steps below:
Go to a newly generated chunk, go to 9, ~, 9 (chunk coords) and stand on the ground
/fill ~-2 ~-4 ~-2 ~2 ~4 ~2 air
Fly up a few blocks, but don't move in x/z
/execute positioned over world_surface run setblock ~ ~ ~ minecraft:spawner{SpawnData:{entity:{id:"minecraft:cave_spider"}}}
/place structure minecraft:buried_treasure ~ ~ ~
(If the chest was placed under the spawner, run
/execute positioned over world_surface run clone ~-2 ~-1 ~-2 ~2 ~-1 ~2 ~-2 ~-2 ~-2 replace move
and try again)
Observe that the buried treasure chest is surrounded on top and to the sides by empty spawners. (Spawners are now empty by default, as opposed to being pig spawners.) This doesn't seem intended; either the spawners should be cave spider spawners, or the game should detect that the block to be replaced is a block entity and use a fallback block instead.
As for whether this issue can still be encountered in the wild, I would assume so but given the extreme rarity of this situation I've never stumbled upon such a case myself. Also, the data mismatch doesn't seem to happen anymore; the worst I was able to get was an empty spawner, which is technically a valid block state, albeit not one that should generate naturally.

I am unable to reproduce this issue, can you confirm that you are still able to reproduce this on the latest version?

I am able to reproduce this issue in 1.21.4 Pre-release 1.
This ticket clones MC-163945.