Fusseel

Yeah this would be a great opportunity for turning Enchantment::isTreasureOnly, Enchantment::isCurse, Enchantment::isTradeable, and Enchantment::isDiscoverable into enchantment tags (with the behavior of the latter two ideally being inverted functionality wise).

Since I just stumbled across the code responsible for this bug anyways, here is a quick analysis. MCP mappings in use are 20200225-1.15.1.

This issue stems from introducing the ravager entity with its special behaviour towards shields into the game.

Where does this bug occur?

When a {{LivingEntity}} (defender) successfully blocks an attack by another {{LivingEntity}} (attacker) using a shield, {{LivingEntity::blockUsingShield}} is called for the defender, taking the attacker as a single argument for it to be knocked back.

Before Minecraft 1.14 {{LivingEntity::blockUsingShield}} would directly call {{LivingEntity::knockBack}} on the attacker, passing on the defender as the argument.

Now LivingEntity::blockUsingShield calls a new method, LivingEntity::constructKnockBackVector on the attacker, providing the defender as the argument. This method does exactly what {{LivingEntity::blockUsingShield}} did previously, so this is where the problem comes from: Defender and attacker are switched twice. In the end LivingEntity::knockBack is called on the defender when it should be called on the attacker.

(Why is the defender not knocked back in game now? Not relevant here, basically there's another call to LivingEntity::knockBack later and both cancel each other out. The second call won't be a problem when this bug is fixed, it's always been there.)

Why was this split made in the first place?

As mentioned ravager entities behave special when it comes to shields. This is achieved by overwriting the new LivingEntity::constructKnockBackVector method in RavagerEntity. The overwritten method expects both entities to be switched, therefor it behaves as intended.
 
How to fix?

Simply switch defender and attacker in LivingEntity::constructKnockBackVector, meaning

protected void constructKnockBackVector(LivingEntity entityIn) {
      entityIn.knockBack(this, 0.5F, entityIn.getPosX() - this.getPosX(), entityIn.getPosZ() - this.getPosZ());
   }

turns into

protected void constructKnockBackVector(LivingEntity entityIn) {
      this.knockBack(entityIn, 0.5F, this.getPosX() - entityIn.getPosX(), this.getPosZ() - entityIn.getPosZ());
   }

.

Note that LivingEntity::constructKnockBackVector is used nowhere else, so there won't be any side effects.

Issue of this ticket has been resolved perfectly.

About the "not able to scroll while sneaking issue": This is not related to sneaking, but to pressing any shift button. And it only occurs when scrolling using a mouse wheel, not when using a trackpad though.

Confirmed for 19w14b. Really hoping this is fixed soon since a lot of related bugs were taken care of very recently. 

The cave and ravine generators (even in the overworld) have a max height value specified up to which they can remove blocks. For nether structures this is y=120 (y=248 for the overworld) and the cause of this bug. 

This was probably added to prevent the generators from reaching the bedrock layer and possibly removing it, but since they are unable to remove bedrock blocks this isn't actually necessary, or at least it could be set to y=128.

This bug is actually a lot older when it comes to nether caves. I've tracked it back up to release 1.6 (from 2013), but it has probably been a thing since the introduction of nether caves in alpha 1.2.

Still an issue in 1.13.

1.13 is affected

1.12 is affected

Ticket is invalid. Parrot spawning works as intended, even after the initial world generation. They spawn on grass blocks as well as logs. Using a super flat world that only contains blocks in the first sub-chunk of every chunk helps a lot when testing mob spawning (no block higher than Y=15).

Invalid ticket. Polar bears do spawn even after the initial world generation on grass blocks as intended. They are just 10 times as rare as rabbits. Tested in 1.12 with the given super flat preset.

Still an issue in 1.12, just saying...

The issue is fixed. Not sure when exactly, but I wasn't able to reproduce it in 1.12. I ran a second test in 1.7.5 with the same world under the same circumstances and the game crashed as mentioned by the reporter. So really is about this issue.

Still present in 1.9.3-pre2.

Still not fixed in 16w15a.

Also still present in 1.9.2.

Still a problem in 1.9.1-pre3.

Can confirm, too. I was testing out the XP and Gold Farm by Snocrash (https://www.youtube.com/watch?v=aBLEbJ9ozRA), it was really obvious there. Since 15w49a all the Zombie Pigmen walk very stutteringly, even up to 1.9.1-pre3. I have noticed that it has become a bit better, but the issue still is not solved. In 15w47c, any snapshot before and all of the 1.8 versions they were just walking smooth like butter.

I do not quiet understand the reason that was given by Marcono1234. It was working in 1.8 and prior versions, why does it only occur since the 1.9 snapshots? Clients are using an internal server since 1.3, so the issue should have appeared back then already, but it did not. So why now in 1.9?

Issue still exists up to latest version, Minecraft 1.9.1-pre3.