navynexus

I would like to point out that this has been a well established mechanic for several years in the Minecraft community. Countless mob farms make use of this interaction to block spider spawns. Removing such an established mechanic does nothing but limit creativity and hurt existing mob farms that heavily rely on this behavior to work the way they do. 

Please consider a revert. Nothing about it breaks the game balance, nor does it have any negative side effects for other aspects of regular gameplay. The only consequence this change will have is hurting players.

Can confirm on 1.19.0.21 Preview on Windows 11, although the issue is slightly different than described.
The spiders don't directly spawn on the buttons, since the spawn attempt will happen on the block next to the button. Therefore, a more accurate description would be the following:
"Buttons don't block spider spawns".

Steps to reproduce:

1. Create a large platform with one button every second block. I have attached a world download of such a setup:

1. Set the time to night (artificial darkness using blocks will also work).

2. Turn on mob spawning & distance yourself to the proper range (24 blocks away from the platform).

Expected results:

Only mobs which do not intersect with the buttons spawn (usually all hostile mobs except spiders).

Actual results:

Mobs including spiders will spawn.

Affects 1.18.10.
Soulsand having a smaller collision box is an essential property of the block. Hackfixing pathfinding over soulsand by making its collision box the same as full blocks is not a proper fix. 

I attached a before and after comparison for my basalt farm example.

After only 15 minutes, the memory usage increases from 419,6MB to 1291,1MB. 
Should the rate of accumulation be constant, my setup would accumulate over 3GB worth of memory leaks per hour.

Affects 1.18.10.

Steps to reproduce:
1. Create a setup that moves a large amount of blocks (e.g. the attached world downloads).
2. Open a hardware monitoring software (Windows Task Manager will work) and write down the memory usage.
3. Launch your contraption.

Observed results:
After some amount of time (usually 1 hour or less will suffice), the memory usage will have increased. The severity of the memory leak will depend on the amount of blocks moved.

Expected results:
The memory usage does not keep increasing constantly.

The memory leak issue will be less relevant for casual gameplay, whereas anything that moves blocks consistently will accumulate memory usage rather quickly (e.g. a medium sized stone farm).

A basalt farm I have built will accumulate over 2.5GB/h in memory leakage, which eventually results in a crash. In my case, the game crashed after around 45min of usage. This issue greatly inhibits the already inferior capabilities of pistons on Bedrock Edition. 

My system configuration is as following:
Windows 11 Pro
Ryzen 5 5600X
16GB DDR4 3600mhz
GTX 1070

My test setup can be found here:

To start the farm, simply find the lever with the redstone lamp in front of the farm that has a sign stating "Farm Toggle".

It's set to x16 and it works. Coincidentally, MCPE-111893 also seems to be working for me, which was also an issue related to anti-aliasing
Edit: The issue persists upon launching the game, but minimizing the window and bringing it back up fixes the issue. Can you try that?

Fixed in 1.16.210.60

It was not fixed by changing any settings in the Nvidia Control Panel, but it seems to be fixed in 1.16.210.60. MCPE-58826 seems to also have been fixed!

I've added one additional comparison: when zoomed in, you can clearly see the difference. The issue appears to be that UI elements are affected by anti-aliasing, whereas in versions without RenderDragon, they are not. I mentioned terrain in my original description - it is likely that that was a mistake on my part.

The issue occurs on both fullscreen and windowed. It has already been occuring in every beta with RenderDragon so far. 
I am running a GTX 1070 on the latest drivers.
It is also probably worth to note that the difference is quite subtle; I imagine it would be easy to not notice any difference without good eyesight.

Upon a little more research, I stumbled upon this: For players, moving blocks adopt their collision box for their future location while they are still in the half extension state. The same can be said with retraction. Entities seem to react to half extended / retracted moving blocks fine and properly collide with them.
In 1.14, this issue was still present for both players and entities, and looking back it seems that entities used to have the same issue.

My guess would be that in order to fix this issue,1. collision boxes of moving blocks need to be properly transitioned when they are in their half extension / retraction state and 2. remove the current temporary fix implemented for slime not launching as a consequence of this behavior (or else behavior as described by @buyifan will persist.)

Affects 1.16.100.59. This is a render dragon only bug

This is not related to the scaling of the spawn range. The mob spawn range does not increase as you go higher, it decreases as you go down. The radius is 24-128 for all simulation ranges 6 and up (Java Parity). However, this radius is cut down in size horizontally from simulation edge despawn chunks preventing spawns from being made inside of them (this matters on simulation ranges 6-10). The chunks within 96 blocks rule is not part of the mob spawn range scaling, as it is present on all simulation ranges and has been for many versions.
The 128 block radius still works vertically as expected, because chunks are 0-256 vertically. Allowing it to reach the full 128 blocks horizontally on simulation distance 12 is only coherent with the scaling and Java Edition parity.
There is little negative impact on gameplay, but it is nonetheless disparity and comes as an unexpected spawning rule to players.

Also noteworthy: In my test setup, the few stray spots outside of the seen area are endermen teleporting right as they spawn.

Note: This limitation should ideally be kept for the aforementioned lag reasons, but increased to a little bit past 128 (about 144) to allow the full 128 spawn range to be made use of on simulation range 12.

This is not a duplicate of MCPE-63223. That report is about the wither skulls not being able to break obsidian.
What is being meant here is that when attacked, the wither does not break obsidian. It is meant to break obsidian, just not during its spawn animation.

This issue occurs to me on Windows 10

@gruva They randomly despawn (which also happens in Bedrock), but not spawn and instantly despawn.
When spawning and instantly despawning, the player never gets to interact with the mob.
Whereas in the random despawn range, which is from 32 radius up until the instant despawn radius, mobs exist for a reason.

I am confused. How can mobs spawning and instantly despawning be marked as Working As Intended?

This issue is marked as fixed in 1.16.0.61, but the described issue is still occuring. In fact, it seems like the instant despawn range has been reduced for sim distance 4❓ .
The changelog in 1.16.0.51 states that mob despawning range is now tied to simulation distance.

Which could mean one of two things: Either the ranges scale depending on your simulation distance, or a mob will instantly despawn when not within simulation distance. I figured it was the latter, but it's not. Meaning that despawning still is a sphere and the mobs despawning midair issue is still present.

I still think that having it configured to despawn mobs instantly outside of simulation distance and removing the R32-54 1/800 despawn chance is a good option,, and even better would be a cylinder that has a 54 block radius and is limited vertically (ideally 128 blocks up and 128 blocks down from the player).

The mention in the 1.16.0.61 changelog is a little vague, so it's hard to draw conclusions from this and I haven't conducted good enough testing yet to determine the proper despawning conditions, but what I can tell you is that the issue still persists.