Right- and left clicking at the same time will cause a block to be placed on top of a block, which then gets removed

Confirmed.

Reason
The game loop happily handles both buttons in the same round, in the order left then right. The block and coordinates for the block that was aimed are kept the same (that is, it does not seem to recalculate the aim target after handling the first button. Thus, it first does left click (remove block) then immediately after does the right click (adds a block) as if the removed block is still there).

Now, one could think that the game checks if the block targeted can accept something to be attached to it. Nope. It only check the object being added if it has some objections to being attached to the target block. Apparently normal blocks have no objections of being attached to air.

One fix

Minecraft.clickMouse(int)

private void clickMouse(int button) {
            ...
        } else if (this.objectMouseOver.typeOfHit == EnumMovingObjectType.TILE) {
            int var4 = this.objectMouseOver.blockX;
            int var5 = this.objectMouseOver.blockY;
            int var6 = this.objectMouseOver.blockZ;
            int var7 = this.objectMouseOver.sideHit;

            if (button == 0) { // LEFT CLICK ON BLOCK
                this.playerController.clickBlock(var4, var5, var6, this.objectMouseOver.sideHit);
                this.entityRenderer.getMouseOver(1.0F);    // <-- ADDED FOR FIX, REPICKS AIMED BLOCK
            } else { // RIGHT CLICK ON BLOCK
                ...
}

Tested on 1.4.7. The fix makes the deletion of the aimed block (happens first) to also rescan for the new aimed block before applying block placement with the right click. Basically, the block under feet will be replaced with the block in hand.

Wouldn't this lag more?

It theoretically causes a tiny bit more processing overhead (which btw isn't 'lag') whenever the left mouse click is used, yes. But it should not be any considerable amount. I'll leave the testing and fine-tuning (or figuring out a better solution) for Mojang. For example, the initial call to getMouseOver is inside its own profiling section, so I'd guess Mojang would like to wrap that added call into one, too.

The solution I gave is more like proof of concept; proofs the reason for the bug, and that it can be fixed (easily).

Affects 13w09b.

Explain to me why this is a bug.
It only effects creative, where naturally you should be able to place blocks easier.
It is highly useful for placing pistons upside down.
It has no negative aspects, and is impossible to accidently do.
I used this behavior a ton, and now it is gone.

For reference: Seems this was "fixed" so that only the left click action (block removing) is done, right click action gets ignored when it happens simultaneously with a left click. (Didn't check the code, just the observed behavior in the client.)