Coral Still Dies When TickSpeed Is 0

coral blocks don’t use random ticks, they use schedulesd ticks.

Ah, oof.

I'm still not really convinced that this behavior is intended. This seems to be the only game update event of its kind that's not affected by a gamerule, so it's rather inconsistent. Additionally, from my experiment there does seem to be randomness to it: try /fill'ing a large area (i.e. 5x5) with coral blocks and you'll notice each one will die in a different rhythm, even though they were all placed at the same time. How comes there's not "randomness" to this for it not to be affected by the gamerule?

This definitely doesnt seem intended. (If anything it's a big oversight) I dont see any way in which the ticks are scheduled and not random.

With the randomness at which coral change to their dead variant, it would be the assumption that they are affected by randomTickSpeed. Which is not the case.

Behavior is still the same in 1.14 Pre-Release 1:

Coral Blocks are updated randomly after being scheduled after being placed or updated.

Using the setblock command will never schedule the random updates, until that block is updated.

You can see this behavior in the fill command as well, as the last block (highest x,y,z values in the area) will always change last.

This seems random enough that it should be controlled by the randomTickSpeed gamerule.

It schedules a random amount of ticks. This is appropriate for this block because the developers wanted a predictable range of decay times.