Breaking snow piles that contain flowers with a shovel simply removes the snow without placing the flower; grasses, stones, and some other plants (e.g. Athyrium ferns) behave normally, as do snow piles broken by hand.

Please confirm you're not just breaking the snow pile and content (i.e. a flower, which would instant-break) too quickly to notice.

Yep, I made sure of it - I tested using a field of dandelions after first noticing, and pointed my shovel at the very edge of the snow pile. When I was testing if it still happened when not using a shovel, I did have an instance of breaking the flower at the same time, but it still played the plant-breaking sound.

Specific flowers I've had this happen with (occurred to me it might be a limited selection):

• Dandelions
• Red & pink tulips
• Lily of the valley

I'll do some more testing tomorrow, see if there is a specific subset of flowers that do it

This proved wildly more difficult to track down than initially anticipated:

• I cannot reproduce this in Creative mode. Breaking a snow pile always places a plant back
• I cannot reproduce this in Survival, with a wooden shovel (importantly, any shovel that does not instant-mine snow layers)
• I can reproduce this in Survival, with any shovel that is sufficient to instant-mine snow (i.e. bronze)

This indicates that there's a specific problem with instant-mine on survival, which does in vanilla have some edge case behavior. Secondly, the sequence of events when this fails looks like such:

1. Client starts breaking a block (Minecraft.startAttack()) at the location of the snow layer
2. Client predicts a block break (instantly, due to low enough hardness), and sends a packet to the server to record the block break
3. Server (integrated), receives the packet and updates the block (it is now a tulip) in the chunk
4. Client continues breaking (Minecraft.continueAttack()). Note at this point, the client is in a weird state - it is ray tracing towards the same block that it originally started breaking, so sends a packet to try and break a second block.
5. Server updates the block below the tulip (removes the snowy state)
6. Server receives the second packet, and does the check - the client was targeting a block, which was instant-breakable, and breaks the tulip (leaving air)
7. Client receives an update, and sets the block broken to air.

The only comparable situation to this in vanilla is if we are breaking a turtle egg from 2 -> 1 eggs (because the hitbox changes, same as a snow layer), and have haste 100 (or similar) so we instant-break it. While trying to isolate the problem, it became obvious that in the vanilla case, step (4) does something different: It sets the block to air, on the client, causing the client to not try and break a second block. This seemed really, really weird - but it means that the client ray traces the block that is actually present there, which realizes it can't continue attacking and break a second instant-break block.

The difference ended up being a subtle difference in how we implemented our "turn into another block on break" from vanilla turtle eggs, to TFC snow layers. This bug probably effects more than just snow layers, although the conditions (needing instant break of both blocks) are probably rare or creative-only (i.e. haste 100)