Pistons do not account for block updates triggered by blocks broken by the extending piston when placing moved blocks, resulting in duplication issues

Current state as of 1.15.2: Blocks broken by pistons no longer trigger block updates, so this issue is mostly fixed. I say mostly, because there are still situations where you can get block updates before step 4 in the list below. One such issue is MC-133541, where you can move a coral in such a way that its supporting block turns into a non-supporting block by the piston's movement. This causes the coral to destroy, causing a block update. However, as the supporting block is also moved, the piston moves the coral to its new location. This issue is detailed in MC-139507 and probably has the same root cause as this ticket (MC-100579).

—

This report is based on this video.

---

1.9 changed the way pistons move blocks . Now, when a piston extends, the following procedure happens:

1. Remember all blocks that will be moved
2. Remember all blocks that will be destroyed
3. Destroy all blocks (triggering block updates)
4. Move all remembered blocks to their new location

There's a problem with this procedure. State changes caused by block updates triggered by blocks destroyed in step 3 are not reflected in step 4 - instead, the blocks remembered in step 1 are placed in their new locations exactly as they were in step 1.

In this context, "change state" refers to the following:

• Block drops as an item
• Block turns into an entity
• Block turns into another block

This can be exploited with the following blocks:

• Rails (drops as item and is kept as block)
• Carpet (drops as item and is kept as block)
• TNT (produces lit TNT entity and is kept as block)
• Dry Sponge (soaks up water but stays dry)

They all share the properties of being movable and being able to change shape immediately upon a block update, which are required for a block to be exploitable in this manner.

Attached is a screenshot showing an example setup to create lit TNT entities without losing the TNT block. Note that all pistons are sticky pistons. Other ways the exploit this behavior are demonstrated in the video linked above.

Suggested fix: Move step 1 after what currently is step 3.