The Bug:
Breaking blocks that can be instantly destroyed slowly breaks the targeted block behind them.
Please note that this is not a visual glitch. The targeted block will be destroyed as normal once the breaking animation on it is complete.
Steps to Reproduce:
Obtain a stack of short grass and switch to survival mode.
While looking at some dirt, constantly place and break the short grass in quick succession.
Observe the block breaking progress of the targeted block behind the short grass.
Observed Behavior:
The targeted block behind the block that can be instantly destroyed slowly breaks and shows block cracks.
Expected Behavior:
The targeted block behind the block that can be instantly destroyed would not break at all.
Linked issues
is duplicated by 64
relates to 3
Attachments
Comments 27

The specific snapshot that apparently introduced this behaviour was Minecraft 1.14.4 Pre-Release 6.
Reopened since this behaviour didn't exist prior to 1.14.4-pre6, as opposed to MC-69865.

Some (maybe distracting) information to add:
The rate at which the block breaks increases if the player is wielding the appropriate tool for the block. It's not always 1 "point" of crackage.
This only works with blocks that are naturally instantly breakable with an open hand; I have not been able to recreate this using efficiency tools on dirt, shears on leaves, or by trying to hit a block through chickens.

This issue becomes very obvious when holding right-click to use bonemeal to grow crops while holding the replacement crop in off-hand. (ie: <hold right>bonemeal, <still holding right>bonemeal, <still holding right>bonemeal, <click left>break , <still holding right>place new crop, <still holding right>bonemeal... and so on). The farmland becomes damaged over time, and eventually breaks.
The "damage" to the farmland does not go away unless the farmland is hit exactly once, directly, without holding right-click, at which point the damage resets.

can confirm in 1.20 Pre-release 1

Can confirm in 1.19.4
Can confirm in 23w44a

I found out, in which version exactly this bug was introduced. In version 1.14-pre5, this bug doesn't occur, in version 1.14-pre6, this bug occurs
can confirm in 1.21
Thank you for your report!
We're actually already tracking this issue in MC-69865, so I resolved and linked this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.