DrAv0011

The geometries shared here contain the fixes for it, it was made in blockbench just by increasing the height of the lower body block by 2 pixels downwards on all of them.
villager_v2 is the one used by the actual villagers, evoker by the actual evoker and villager is the model which the witch uses to render itself (maybe it would be better to make the witch it's unique model)

This is an example of a custom head, which simulates a player head model, which contains a first 8x8 cube centered on the block space, and a second cube which is a copy of the first but inflate 0.5 so it can have the second layer of what player skins heads have.
That second layer clips a bit on the ground so it is displayed accordingly to where it would be if it was on the player head, and if I were to move it up so it does not clip it would look as that second skin layer would be offset and not according to the player model, or if moved the whole block up, it would be floating for skins which do not have the outer layer.

This is another exaple of what this issue breaks, as stated on Lord Nubs comment, to be in parity with Java Edition and how the vanilla game behaves I think it should be extended to 3x3x3 max size, or the equivalent of bounds from (-1.0,-1.0,-1.0) to (2.0,2.0,2.0)

Confirmed on 1.17.11 Release

How would this behave on large selectors? If it is @a for example is there are, say 10 players, will it just display the first of them and then cut, same as when text is too long?
What about a score which tracks nearest player, and there are many players, it would need to update the sign somehow constantly.
I know in Java Edition we can place signs with text on them with commands and on placing they will update the text on it, and will not change until another sign is placed on its place.
But we cannot do that on Bedrock, maybe if structure blocks on load they updated signs to recalculate the score we could work with that.

Also worth mentioning on written books, and npcs, selector and scores do not work either.

Slowly more old/low-end devices have been removed from the supported list. I think at this point we could standarized Simulation Distance 6 and maybe even 8. That could help solve this issue and a some more like mob spawning/despawning.

Neither works on stonecutters as noted in MCPE-128423

Neither works for trading with villagers as noted on MCPE-128486

Adding this file in the ui folder in any resource pack will enable the panorama overlay.
What it does is to add in the ui a linkn to the overlay texture and add it to the controls so it does render in the main screen

We use that new syntax @Mega_Spud showed in the comment, but the problem here is that we cannot use that new syntax on
/execute detect or /testforblock
commands, so we can add to the world blocks using the new syntax, but we cannot test/check for them with specific arguments.

Apart from what Jake said, other blocks as log, leaves and other can set with value id's above the existing ones with them defaulting to 0
/setblock ~ ~ ~ log 20
Would set a log 0 block in that position

Some other blockstates as powered redstone dust or redstone dust facing to only one specific side cannot be placed
And other blocks as redstone torch are divided into 2 blocks, redstone_torch and unlit_redstone_torch, when they should be one block with multiple states.

I would suggest to change to a format similar to java edition 1.13+ setblock where you can set each block property manually.

/setblock ~ ~ ~ redstone_wire[power=15]
/setblock ~ ~ ~ oak_log[facing=north]

With the changes to new custom blocks in addons that are rn on experimental, when this changes get added to the vanilla blocks, it would be easier to access the properties of them, and with that allowing to fix this issues we have right now.

This is my proposition for this
Having the simulation areas and the despawn radius

If a mob leaves the simulation area or the 128 radius circle will despawn. The blue-tinted zone shows where mobs should instantly despawn.

I think this way is the most appropriate approach to this problem, as users do not need to know in which simulation distance they are, as it will be always the same behavior and radius for everyone when it comes to vertical behavior, and on sideways one, does not differ that much.

128 block radius sphere

4 Simulation distance 3D representation of the despawning area

For this to be achieved a lazy chunk system as @Reed Cartwright said would be a good way to go with.

In this way, players won't need to know what despawn radius sphere is needed for their simulation distance, and farms and other behaviors would be more universal.

the issue still there, removed the fixed in 1.13 text

HIgh chances work as intended, useful for marketplace map makers

HIgh chances work as intended, useful for marketplace map makers

Even that this is considered WAI, should not be, in Bedrock Version is possible to dye Wool and Beds from any color to any other one.

All 1.16 betas until 1.16.0.58 also have this visual glitch.

Resource Pack which fixes the issue
is just one number change on the vanilla resource pack
File attached to the issue with name: XpBarOffsetFix_v1.1.0

also a random vid showing how I fixed
removed not working link

Checking again that pack and after reading [Helper] Doubletoad74's comment https://bugs.mojang.com/browse/MCPE-46975?focusedCommentId=664430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-664430
This change would also fix this issue. (Tested on Win10 and Samsung Galaxy A40)

"hotbar_chooser": {
    "type": "panel",
    "size": ["100%c", "100%c"],
    "$ignore_desktop": true,
    "$ignore_pocket": false,
    "variables": [
      {
        "requires": "($desktop_screen and not $education_edition)",
        "$ignore_desktop": false,
        "$ignore_pocket": true
      }
    ],

    "controls": [
      {
        "desktop_hotbar@hotbar_panel": {
          "ignored": "$ignore_desktop",
          //Changed offset from -4 to -3
          "offset": [-3, 0]
        }
      },
      {
        "pocket_hotbar@hotbar_panel": {
          "ignored": "$ignore_pocket",
          "size": ["100%c", 18],
          "offset": [-3, -2]
        }
      }
    ]
  }

As noted changing the offset on the base hotbar_chooser fixes both creative and survival/adventure hotbars offsets

Client-Side Resource Pack which fixes the issue.

A lot of the redstoners in bedrock use this bug to make our contraptions smaller, as @silentwisperer said it does not break anything in the game and just allows users to make better contraptions in the game

Also if you think it does not look as it worked as intended read this

Pistons are a redstone component which contains redstone dust inside it
So when the piston gets powered its insides are softpowered, and as some of the signal is used to energize the piston it remains only a little strenght (consider inside of piston always receives 1 of strenght, and uses 0.9 to power itselft and has remainng 0.1) which cannot power a dust or a repeater as they need at least 1 strenght signal, but enought to power a redstone torch as it with any strength can be powered.

Hope you think this properly, even that my attempt of explaining this is not the best, a lot of people would be concerned if this is removed and in case is marked as Work As Intended would make users happy and they will stop having that scare of something that is really usefull and does not break the game will be removed.

@[Mod] tryashtar yes is resolved in 1.14.1

as a feedback comment, from my opinion this is a useful feature in some cases and as it has been here for a lot of time is considered a feature by me