Myren Eario

Here´s a less obfuscated version of the relevant part of the code. It´s the beginning of the moveEntity() method in the Entity class in 1.12 MCP, except that I renamed some variables.

public void moveEntity(MoverType moverType, double amtXIn, double amtYIn, double amtZIn)
    {
        if (this.noClip)
        {
            this.setEntityBoundingBox(this.getEntityBoundingBox().offset(amtXIn, amtYIn, amtZIn));
            this.resetPositionToBB();
        }
        else
        {
            if (moverType == MoverType.PISTON)
            {
                long i = this.world.getTotalWorldTime();

                if (i != this.lastTimePushedByPistons)
                {
                    Arrays.fill(this.distanceMovedByPistonsInThisGtick, 0.0D);
                    this.lastTimePushedByPistons = i;
                }

                if (amtXIn != 0.0D)
                {
                    int j = EnumFacing.Axis.X.ordinal();
                    double d0 = MathHelper.clamp(amtXIn + this.distanceMovedByPistonsInThisGtick[j], -0.51D, 0.51D);
                    amtXIn = d0 - this.distanceMovedByPistonsInThisGtick[j];
                    this.distanceMovedByPistonsInThisGtick[j] = d0;

                    if (Math.abs(amtXIn) <= 9.999999747378752E-6D)
                    {
                        return;
                    }
                }
                else if (amtYIn != 0.0D)
                {
                    int l4 = EnumFacing.Axis.Y.ordinal();
                    double d12 = MathHelper.clamp(amtYIn + this.distanceMovedByPistonsInThisGtick[l4], -0.51D, 0.51D);
                    amtYIn = d12 - this.distanceMovedByPistonsInThisGtick[l4];
                    this.distanceMovedByPistonsInThisGtick[l4] = d12;

                    if (Math.abs(amtYIn) <= 9.999999747378752E-6D)
                    {
                        return;
                    }
                }
                else
                {
                    if (amtZIn == 0.0D)
                    {
                        return;
                    }

                    int i5 = EnumFacing.Axis.Z.ordinal();
                    double d13 = MathHelper.clamp(amtZIn + this.distanceMovedByPistonsInThisGtick[i5], -0.51D, 0.51D);
                    amtZIn = d13 - this.distanceMovedByPistonsInThisGtick[i5];
                    this.distanceMovedByPistonsInThisGtick[i5] = d13;

                    if (Math.abs(amtZIn) <= 9.999999747378752E-6D)
                    {
                        return;
                    }
                }
            }

and then there´s the rest of the moveEntity method.

While I don´t like this behavior, it looks intentional, so I don´t think this bug report will go very far.

"Is this still in Minecraft 1.11?"
Yes.
Minecraft 1.11 should be added to the affected versions of this report.

"Is this a problem?"
No.
(at least if you ask me)

Observers do power blocks strongly. They just don´t send enough block updates. So if you use an observer to power something through a block, you´re creating BUDs.
So the actual bug is this one:
https://bugs.mojang.com/browse/MC-108696

If this bug report ( MC-108695 ) is considered to be a dupe of ( MC-108054 ), then I will heavily edit that bug report ( MC-108054 ), because there are the following differences between the two bugs:
1. Since 16w41a it´s not enough to move and reload the observers to produce the bug. You need to update them first, otherwise the bug doesn´t occur.
2. /setblock commands work fine in 16w41a
3. Since 16w41a observers now don´t always rotate towards +z anymore, but they also rotate towards other directions,
Basically I will have to rewrite the entire MC-108054 bug report, and I thought it would be more logical to just submit a new bug report for this. But I will just copy paste what I´ve written here into MC-108054 if you want.

A similar bug is also, that arrows lose their punch enchantment effect when being reloaded ( MC-59626 ). Both of these bugs occur, because the nbt structure of arrows is incomplete. Each of these bugs should be easy to fix, by implementing new nbt tags to the arrow, which could be done by just adding 1 or 2 lines of code to the functions which write and read the nbt data of the arrow.

Can you give an example of a 0 tick pulse monostable for MCPE? Or what exactly did you test in MCPE that made you conclude that there are 0 tick pulses? Because the update system is as far as I can tell very much different from the PC version and I didn´t find any 0 tick technology that works in MCPE.
Edit: I found something that could be considered to be a 0 tick pulse. Ignore this.

It´s not entirely accurate to say that the piston completely disappears at the retraction. If a piston retracts he´ll become a block 36 for 2 gticks (Block 36 is a block which handles block movement. In setblock commands block 36 gets called "piston_extension" and in the code it gets called BlockPistonMoving). And block 36 does not have a solid top surface, which causes flower pots to pop off. Also block 36 has no visual hitbox (but he has a collision hitbox since 1.9), and that´s why you can see through him. But there´s still a block there. It´s just a rather weird block. Just wanted to add that.

Well, there´s nothing I can say against adding a gamerule.
The only thing I might want to add is, that if "the piston should pulse" is just as legit as "the piston should turn into a derp piston", then I think it would be better if the piston pulses, because if the piston turns into a derp piston then absolutely nobody is happy, while if the piston pulses, then at least some people are happy. So I would say the piston in the loop should pulse, not because of logical consistency reasons, but because of utilitarian and game design reasons.
But again, if it´s just an optional gamerule, then it´s just an optional gamerule.

So you don´t want to "patch all 0 tick pulses", but you just want to make the update order more simple, logical, intuitive and remove all hashsets and location dependencies. This is something I completely fully support. But the stuff you´ve written in the bug report is about the "existence of 0 tick pulses in general", and I can´t consider that to be a bug. You can simplify update order and make 0 tick pulses more intuitive, and I support that, but you can´t remove the update order and all 0 tick pulses. So I won´t support "patching 0 tick pulses out of the game".
Now I think there are even more examples where 0 tick pulses are unavoidable:
Let´s look at this:
http://imgur.com/b1RqoCx
This is just like my previous example, except I added another piston on top. If I flick the lever on, the piston on top will recieve a 0 tick pulse. Now since we already established that the piston on the bottom right will react to the 0 tick pulse, I think the piston on the top should also react to the 0 tick pulse. There´s no relevant difference between the piston on the top and the piston on the bottom right, and they both get powered and depowered at the exact same moments in the update order, by the exact same piece of redstone dust, so I think they should behave in exactly the same way.
Do you agree?
If yes then we have something called a 0 tick pulse monostable.
And there are even some 0 tick monostables which actually get used which kind of work like this. For example this 0 tick monostable relies on the same principle: http://imgur.com/PnEZabk
So if you think it´s ok to keep this, then you might want to add another edit to your bug report, because the bug report makes it look like you want to remove such monostables.

Just out of curiosity I would like to know how you would imagine the game works without 0 tick pulses. Basically I´m asking: What is the intended behavior?
For example the following contraption:
http://imgur.com/KPDVUL4
In the current version if you flick the lever after the repeater delay, the piston on the right will get a 0 tick pulse, and within a single gametick he will extend and then retract.
I would not know what should happen in this situation if we do not allow pistons to react to 0 tick pulses.
Do you want, that the piston on the right doesn´t react, because it´s a 0 tick pulse? That solution doesn´t work here, because if the piston on the right doesn´t extend, then the piston on the left never retracts, and then the pulse never gets turned off, which means that the pulse wouldn´t be a 0 tick pulse, which means the piston on the right should extend.
Do you want the piston to extend and wait one gametick before retracting? Well in this situation we will see the piston extending for 1 gametick, even though the redstone line is off. Now since you´ve previously said, that it is illogical if there is "a moment where you will see the piston retracting although the redstone line is ON." then you will also consider it illogical if a piston extends even though the redstone line is off. So that solution doesn´t work here either.
So what is the intended behavior in this situation? I find a 0 tick pulse in this situation quite logical.
Another note about the " you will see the piston retracting although the redstone line is ON.": This is normal piston behavior and can be recreated even without 0 tick pulses. When you retract a piston it will ignore any other pulses until it finishes its retraction. You can recreate this situation even without 0 tick pulses, by retracting a piston and powering the piston again in the next gametick. Even though the piston will be powered 1 gametick after it started to retract, it will continue to retract. You will see the piston retracting although the redstone line is on. Now you might consider this to be illogical, but this illogical part is not related to 0 tick pulses. If we "fix" 0 tick pulses (whatever that means), then this illogical part will still be in the game.

Confirmed for 1.9.1-pre3
(at least partially confirmed; completely confirmed are the following:
Blazes killed by tamed wolves never drop any blaze rods in 1.9.1-pre3;
Spiders killed by tamed wolves never drop any spider eyes in 1.9.1-pre3;
I haven´t tested other things yet)

Fixed in 1.9-pre 1
And it was probably related to: https://bugs.mojang.com/browse/MC-89119

This bug seems to be also related to MC-89146 .

This looks related to MC-73302, which was a big unintended bug, which has been fixed in 1.9. I think items bouncing off stairs was unintended, and that they don´t bounce anymore is not a bug, but a fix.