Conrad Dowding

Affects 1.20.40.20, Additionally, if a piston pushes a jungle log with a cocoa bean in line with the piston the cocoa bean does not break, see cocoa piston.png; if the piston is powered the cocoa bean stays attached. Also a single bean pushed by a piston does not break, see floating bean.png This behaviour has changed since 1.16.100 where the cocoa bean would both push any blocks beyond it and also break off.

Also applies to rooted dirt

Slabs have now been changed as of 1.19.40.22 to use the old system so deepslate, copper and mud can use the 0/1 after the name to specify lower and upper slab respectively, but their stairs still use the newer system as described above.

There are a few different permutations that give different errors, depending on whether you use blockstates, data values or a mix:

Stairs

For all of these examples I have rows of polished andesite stairs in the area being filled of all eight different orientations

All commands should be trying the same thing, the expected result: south facing normal stairs only are replaced

Test 1: fill blockstate replace blockstate

fill ~~~ ~10 ~-5 ~10 polished_deepslate_stairs["upside_down_bit":false,"weirdo_direction":3] replace polished_andesite_stairs["upside_down_bit":false,"weirdo_direction":3]

Actual result: all stairs are replaced by default stair facing East

Test 2: fill data value replace data value (using diorite as deepslate does not support data values)

fill ~~~ ~10 ~ ~10 diorite_stairs 3 replace polished_andesite_stairs 3

Actual result: As expected

Test 3: fill blockstate replace data value

fill ~~~ ~10 ~ ~10 polished_deepslate_stairs["upside_down_bit":false,"weirdo_direction":0] replace polished_andesite_stairs 3

Actual result: Syntax error: Unexpected "3": at "te_stairs >>3<<"

Test 4: fill data value replace blockstate

fill ~~~ ~10 ~ ~10 polished_diorite_stairs 3 replace polished_andesite_stairs["upside_down_bit":false,"weirdo_direction":3]

Actual result: Syntax error: Unexpected "[" at "ite_stairs >>"upside_do"

For slabs 

Expected result only polished Andesite top slabs are replaced with top slabs

Test 1: fill blockstate replace blockstate

fill ~~~ ~10 ~ ~10 polished_deepslate_slab[“top_slot_bit”:true] replace stone_block_slab3[“top_slot_bit”:true]

Actual result: All slabs are replaced with top slabs

Test 2: fill data value replace data value (using polished diorite as deepslate does not support data values)

fill ~~~ ~10 ~ ~10 stone_block_slab3 13 replace stone_block_slab3 10

Actual result: As expected

Test 3: fill blockstate replace data value

fill ~~~ ~10 ~ ~10 polished_deepslate_slab[“top_slot_bit”:true] replace stone_block_slab3 10

Actual result:  Syntax error: Unexpected "10": at "ock_slab3 >>10<<"

Test 4: fill data value replace blockstate

fill ~~~ ~10 ~ ~10 stone_block_slab3 8 replace stone_block_slab3[“top_slot_bit”:true]

Actual result:  Syntax error: Unexpected "[": at "ock_slab3>>[<<top_slot_"

Newer blocks such as mud, deepslate copper etc use a different way of determining orientation. To get a  mud top slab use mud_brick_slab["top_slot_bit":true]

The new blocks such as copper and deepslate use a different format for their orientation, you now need to specify the upside down bit and orientation separately. For example the following command will set a south facing upside down cut copper stair below you

setblock ~ ~-1 ~ cut_copper_stairs["upside_down_bit":true,"weirdo_direction":3]

Note there is no space between the block and the square bracket. The fill command works the same way.