Mario Welzig

spelled wrong
Tags can't contain spaces, I added the other two.

Yes, still happens in both 1.10.2 and 16w42a

Here's the updated source (deobfuscated manually, so some names might ne inacurate):

EntityArrow.onCollideWithPlayer(EntityPlayer)

public void onCollideWithPlayer(EntityPlayer player) {
    if((this.worldObj.isRemote) || (!this.inGround) || (this.arrowShake > 0)) {
        return;
    }
    boolean flag = (this.canBePickedUp == EntityArrow.pickupEnum.landed) || ((this.canBePickedUp == EntityArrow.pickupEnum.flying) && (player.capabilities.isCreativeMode));
    if((this.canBePickedUp == EntityArrow.pickupEnum.landed) && (!player.inventory.addItemStackToInventory(j()))) {
        flag = false;
    }
    if(flag) {
        this.playSound(SoundLibrary.entityItemPickup, 0.2F, ((this.rand.nextFloat() - this.rand.nextFloat()) * 0.7F + 1.0F) * 2.0F);
        player.onItemPickup(this, 1);
        this.setDead();
    }
}

@unknown You may be right, I'm referencing the 1.8.8 source.

Yes, as I said: No problem with the NBT data.

net.minecraft.entity.projectile.EntityArrow.onCollideWithPlayer(EntityPlayer)

...
if(!this.worldObj.isRemote && this.inGround && this.arrowShake <= 0) {
    // pick up arrow
}
...

As you can see, inGround and arrowShake (which maps to the NBT tag 'shake') do have the right values, however the first condition (!this.worldObj.isRemote) is never met.
The onCollideWithPlayer method should be executed twice per tick; Once by each the client and the integrated server.
!this.worldObj.isRemote is true if the current execution is caused by the server, so because it always fails we can conclude that the server doesn't register the collision.

@No Name1 Both arrows have their OnGround tag set to 0 but the inGround tag is the important one 🙂

Confirmed for 15w51b.

Confirmed for 15w51b... very strange
Doesn't seem to depend on orientation.

I've crouched on either side of the burning block and there is no side which always or never sets the player on fire. I guess it's a matter of rounding errors as the pattern seems random.

Confirmed for 15w51b, very annoying when working with auto-completed coordinates.

Can't confirm with 15w51b.

Alright, found the problem:
Usually, the method Entity.playStepSound checks whether the block below the entities feet is a liquid.
However, with the new update said method has been overridden the EntityChicken class (and other entity classes e.g. EntityCow) to play the new individualized step sounds.
An unfortunate side effect is that the liquid-check is getting bypassed completely.

My suggestion to Mojang: Stick to the system you use for death and hurt sounds with methods returning the sounds name and leave the checking to the Entity.playStepSound method.

EntityChicken.java

protected void playStepSound(BlockPos pos, Block blockIn){
    this.playSound("mob.chicken.step", 0.15F, 1.0F);
}

If a conditional command block is powered but the preceding command block didn't succeed, the conditional block won't run but will also deactivate all comparators facing away from it. This is intended behavior though.
The success message inside of the conditional command block may come from an earlier execution and just hasn't be overridden as the command block didn't execute again since then.
Does the time of the output message change when you power the block?

Ok, that's weird... For some reason the player collision is only registered by the client but not by the integrated server, which is responsible for handling the pickup.

Confirmed for 15w51b, after reentering the world the arrow can be picked up again, so there is indeed no problem with the NBT data.

Stil valid for current snapshot 15w51b.

Minecrafts sound system allows any sound to be paused and stopped regardless of the stream parameter (just open the ingame menu and any sound will be paused). The difficulty in implementing your suggestion is that once played, the actual sound object is no longer tied to the causing entity in any way other than the playing position, however the entity may have moved since the sound started. So basically it is currently impossible to decide, which sounds should be stopped when the entity dies.

You can create a backup of your server list by copying the /.minecraft/servers.dat file.

This stil applies to the current snapshot 15w51b.

Still occurs in current snapshot 15w34d.