A button on TNT ignites 1 to 4 of the surrounding TNT depending only on which side it is mounted

Build a plus shape of four TNT blocks around one air cell and mount a button (or lever) in that cell on one of the TNT blocks. Pressing it ignites a different number of the four TNT depending only on which TNT the button is mounted on:

• mounted on the west TNT: only that TNT ignites

• mounted on the east TNT: west and east ignite

• mounted on the north TNT: west, east and north ignite

• mounted on the south TNT: all four ignite

The build is perfectly symmetric; rotating it changes the outcome.

Cause:

Neighbor updates run in the canonical order west, east, down, up, north, south (NeighborUpdater.UPDATE_ORDER); for the four horizontal TNT that means west, east, north, south. Each TNT primes inline in neighborChanged and immediately removes its block. The moment the TNT the button is mounted on primes, the button loses its support block and pops off as an item - and every TNT later in the update order no longer sees any power. So exactly the supporting TNT and the ones updated before it ignite, and the rest never do. (Verified on the official 26.2 server jar with nothing else installed; the same happens with a lever.)

Steps to reproduce (commands, any world, standing anywhere):

1. /fill ~-1 ~4 ~-1 ~1 ~4 ~1 minecraft:smooth_stone

2. /setblock ~ ~5 ~-1 minecraft:tnt, /setblock ~ ~5 ~1 minecraft:tnt, /setblock ~-1 ~5 ~ minecraft:tnt, /setblock ~1 ~5 ~ minecraft:tnt

3. /setblock ~ ~5 ~ minecraft:oak_button[face=wall,facing=east,powered=true] - only the west TNT ignites

4. Repeat with facing=north: three ignite. With facing=south: all four. Hand-pressing a normally placed button behaves the same.

What I expected:

All four TNT ignite in every orientation: they are all adjacent to a powered button, and a symmetric build should not behave differently under rotation.

A note on the fix shape (both shapes implemented as a toggleable mod and verified against this reproduction):

TNT is the update sweep's only inline self-removing reactor, so the fix can stay local to it. Two shapes, in order of preference:

1. Defer the prime and removal to the end of the current update sweep. The sweep already has a natural completion boundary (CollectingNeighborUpdater.runUpdates unwinding); collecting TNT primes during the sweep and running them when it completes means every neighbor is notified while the button still has its support, ignition stays in the same game tick, and the reproduction ignites all four TNT for every button facing with no timing change at all.

2. The simpler variant: schedule a 1-tick block tick from neighborChanged instead of priming inline, and prime unconditionally when it fires. Unconditionally matters: the powered condition was already evaluated at notification time, and re-checking power when the tick fires just recreates the same race one tick later (the supporting TNT still pops the button first); the tick system already guarantees the block is still TNT. With this shape all four TNT ignite for every button facing. Its tradeoff is one game tick of added ignition latency, which timing-sensitive contraptions would notice - which is why shape 1 is preferable.