/setblock & /fill ignore the specified block ID when replacing door with different door type

To reproduce

Place a closed spruce door in the world.

Use /setblock <x y z> minecraft:oak_door to replace the lower half of the door, or /setblock <x y z> minecraft:oak_door[half=upper] to replace the upper half. The command fails with “Could not set the block”.

Use /setblock <x y z> minecraft:oak_door[open=true] to replace the lower half of the door, or /setblock <x y z> minecraft:oak_door[half=upper,open=true] to replace the upper half. The command succeeds and both halves of the door open, but no oak blocks are placed; both halves remain spruce.

Code analysis

This happens because of the implementation of DoorBlock::updateShape(). It determines that a neighboring block is the paired door half if the neighbor is in the right position, is instanceof DoorBlock, and has the right half property. If such a neighbor exists, updateShape() copies the entire block state of that neighbor and just replaces the half property. Because it never checks that the neighbor has the same block ID, only that it is a door of some kind, this can cause updateShape() to return a different block ID than it received.

BlockInput::place(), used by both /setblock and /fill, runs updateShape() for all neighbors to fill in the unspecified block state properties (unless strict mode is enabled). It then overwrites the user-specified block state properties back to the user-specified values, but it does not do the same for block ID.

The simplest fix would be to replace neighbourState.getBlock() instanceof DoorBlock with neighbourState.is(this), which is what other paired blocks like tall plants and beds do. Then it would only consider a block to be the door’s paired neighbor if it had the same block ID. Alternatively, doors could continue pairing with other door types, but should only copy their properties and not their block ID.