bodakugga

Cannot reproduce. They emit soul sand particles, which is the same as when breaking them from other sides. They have been emitting soul sand particles ever since they were introduced in 1.4 (October 2012), and soul sand is intentionally specified as the particle texture in their model file (skull.json):
{
"textures": {
"particle": "minecraft:block/soul_sand"
}
}

As this has been closed by a moderator, can I ask for any source for this being intentional behavior? It’s clear to me that mushrooms generating on logs is intentional, but the fact the game doesn’t actually support this placement and causes the mushrooms to break when updated is very obviously not intentional behavior.

The bug report is about mushrooms breaking due to them being unsupported, not about them generating in the first place.

This is a general issue with closed fence gates and standing bells, which provide central support. You can also place other blocks that require central support on them, e.g. torches or pressure plates

Can confirm.

Can confirm. This also affects TNT that would ignite by catching fire from a nearby fire/lava block or a shot flaming projectile. In Bedrock, in all such cases TNT is not deleted.

Can confirm. In Bedrock, TNT minecarts can’t be primed in any way when tntExplodes is off.

Can confirm, In Bedrock, primed TNT remains but won’t cause an explosion when its fuse runs out.

Firefly bushes have a larger horizontal range in Bedrock. It would be neat if the vertical range was also increased by a few blocks in both editions.

This behavior is completely consistent with all other flower blocks.

"Center support" specifically refers to blocks that have solid 2x2 central pixels on the top face (this is also how placement for blocks like torches or lanterns works). I agree it looks weird, but this is how it's defined in code.

Can't reproduce with glass. Cactus flowers can be placed on all blocks that provide central top support, which includes glass, stained glass, tinted glass, glass panes and stained glass panes. Can confirm with leaves-

Separate issues. Dry grass can be placed on the same blocks as dead bush, which doesn't include farmland (reported here: MC-168262). Cactus flower requires central top support, which farmland doesn't provide.

Likely intentional, the 1.21.70.22 Bedrock changelog explicitly states that leaf litter can be placed on all blocks that provide center support (i.e. fences, walls, chains, end rods, etc):

Leaf Litter can now be placed on any block which provides center support

Can confirm. The emissive texture lacks interpolation in Java.

1.21.70.20 has fixed many of these. The only remaining issues are:

• Mangrove propagule

• Hanging mangrove propagule

• Potted mangrove propagule

• Wall- and ceiling-mounted amethyst buds/crystals

• Calibrated sculk sensor (amethyst crystal)

• Campfire (flame)

• Soul campfire (flame)

• Big dripleaf (stem)

• Small dripleaf (stem)

• Pumpkin stem (this is also an issue in Java)

• Melon stem (also in Java)

• Seagrass

• Tall seagrass

The following seem to be partially fixed, but the old model is z-fighting with the new one:

• Kelp top

• Nether sprouts

• Crimson fungus

• Warped fungus

• Potted flowers

• Potted saplings

• Potted mushrooms

• Potted fern

• Potted dead bush

• Potted azaleas (inner planes)

• Potted nether fungi

• Potted nether roots

1.21.70.20 fixed most of these except seagrass and tall seagrass.

I think deciding whether this is invalid/feature request or a valid issue should be up to the Mojang triage team. Similar plants can be planted in flower pots, so expecting these to also be plantable seems a logical conclusion (unlike some of the blocks from the related issues - vines and crops in particular). I'll also add that azaleas were initially not-plantable in flower pots, it was reported here (MC-214684), the issue was deemed valid by Mojang and subsequently fixed in 1.17-pre1

Can confirm. This is the relevant piece of code from the getDestroySpeed method in net.minecraft.world.entity.player.Player.java

if (this.hasEffect(MobEffects.MINING_FATIGUE)) {
	float f2 = switch (this.getEffect(MobEffects.MINING_FATIGUE).getAmplifier()) {
		case 0 -> 0.3f;
		case 1 -> 0.09f;
		case 2 -> 0.0027f;
		default -> 8.1E-4f;
	};
	f *= f2;
}

If mining fatigue were to properly follow the 0.3^level formula (as it does for level 2 (case 1)), level 3 (case 2) should have been 0.027, and level 4 or more (default) should have been 0.0081. This can also be confirmed by actually trying to reproduce the issue in game, instead of going by memory.

This could be intentional or just a small mistake, but this is up to Mojang to decide.

This was probably marked as "fixed" internally, so I suggest opening a new ticket for the other two suspicious stews. Other half-fixed reports (e.g. MCPE-189881 and MCPE-40646) got new tickets for the remaining issues (MCPE-189881 and MCPE-188463)