tryashtar

Wolves attack skeleton-type mobs including parched all by themselves, so I have no clue why you don’t observe the wolf attacking.

When I correct the spacing of your command, add the omitted UUID, and change to a different mob that wolves don’t automatically attack, it also works fine for me.

/data modify entity @n[type=wolf] angry_at set from entity @n[type=husk] UUID

Your description, command, and steps do not demonstrate a bug
rotated as changes the rotation of the command. say hi does not depend on rotation in any way.

Can't reproduce. Make sure you're not in creative mode

The passing of time is global, not per-dimension

Was it like this when you found it? Can you send your world seed?

“Enchanter” seems updated; “Librarian” is still wrong

This was intentional in the changelog:

The programmer art rabbit textures have been removed following the re-modelling of the rabbit

I should point out that the Bedrock programmer art equivalent (Classic Texture Pack) does revert these models, and even reverts the zombified piglin model. However, this behavior is affected by a major bug (MCPE-234734), so it’s unclear what the intended behavior for Bedrock is.

As for Java, the ability to change mob models in resource packs does not currently exist.

fillbiome is similar to forceload in that it accepts block coordinates as input, but only actually operates on the world at a coarser scale. For forceload, that scale is chunks. For fillbiome, the scale is “quarts” – 4x4x4 block sections. Each chunk is 4 quarts wide in both directions.

Here is the grid of quarts in your repro world:

You’ll notice that between your two signs, there are exactly two quarts. That’s why the command says “2 biome entries set.”

However, biomes are “fuzzed” to make the edges look more natural, making individual blocks sample their biome from up to a few blocks away from the quart in which they reside. It just so happens that in your test, most of the blocks near the second sign happen to sample from the adjacent quart (+1X, just behind the leaf wall). They appear unaffected, since that quart wasn’t in your command’s bounds. Many of the blocks past the second sign happen to sample from the sign’s quart (-1Z). They appear affected, since that quart was in your command’s bounds.

The area is not “completely separate and non-touching.” It’s within 2 blocks of the affected region, which is completely expected according to the description of the command as “not matching input precisely.”

I hope this explanation was satisfactory.

Java translations are done by the community on crowdin, so you can suggest a change there

From the 22w46a changelog:

fillbiome
Changes biome entries for an area. Note that biomes are not stored per-block, so affected positions may not match input precisely.

I cannot reproduce this.

Which issues are you referring to that affect 1.16.4 - 1.19.4?

Which security vulnerabilities are present in these versions?

By definition no old version can receive updates, since an update is a new version.

I was looking into this, and I think it might be caused by GLFW not finding the key names. I’d be curious to see your options.txt and maybe an F3+C crash report for the LWJGL version.

Reproduction on particular chests on seeds will be affected by MCPE-161133

Please include steps to reproduce this in a vanilla environment, and a description of how it affects the game.

Confirmed. This is caused by the item/amethyst_bud model overriding the fixed display of its parent item/generated in order to move it up slightly. The 180-degree rotation from item/generated is not included and so is overridden to 0.

This also causes amethyst buds and clusters to be mirrored when equipped in the head slot. No other items I found appeared to be affected in a similar way.

I believe this duplicates MC-143716

Nicely spotted. Would you please consider creating separate reports for these separate issues?