Normal Pistons also spit out theire blocks with a short signal

I see MC-108 in that video, but nothing else. Please show me a redstone contraption that clearly behaves differently now than in 1.12 (for example light turns on in only one of the versions).

I haven't tested it yet, so far I can say:
1. That the redstone block doesn't power the redstone next to it while moving is another bug: MC-123217
2. I see nothing powering the sticky piston.

It does behave diffrent
"Please show me a redstone contraption that clearly behaves differently now than in 1.12"
Sure

1.12.2 : https://streamable.com/t7i7l
1.13 : https://streamable.com/i4lv5

what happens in 1.12.2 - lower : one left side there are two repeater wich take 4 gameticks, the other side is a zero tick pulse generator chained to a normal piston
the zero tick generator takes 2 gameticks, pushing out the redstoneblock 3, thus taking  5 gameticks. the right piston extends first as its one gametick earlier

whatt happens in 1.13 : one left side there are two repeater wich take 4 gameticks, the other side is a zero tick pulse generator chained to a normal piston
the zero tick generator takes 2 gameticks, pushing out the redstoneblock 0, thus taking  2 gameticks. the left piston extends first as its 2 gametick earlier

(the slimeblock just resets the redstoneblock that gets pushed out)

is this good enough?

No, it's not. 0-ticks are a bug as well: MC-8328
It's such a shame that redstone is so broken that apparently not even good redstoners like you apparently are, even know anymore what's intended and what's not.
But can you please still try to give me an example that behaves differently now and does not rely on other bugs?

if a 0 gametick signal reaches the piston, itll spit it out after 0 gameticks instead of 3

if a 1 gametick signal reaches the piston, itll spit it out after 1 gameticks instead of 3
if a 2 gametick signal reaches the piston, itll spit it out after 2 gameticks instead of 3

same prinzip
but the 0 tick was the easiest to build

and yeah i knew 0 ticks were probably not intended
but i thought this is more or less an official part of the game, as it doesnt do any hard and adds a lot of extra content

Sticky pistons spitting out their blocks is a bug as well! MC-122911
You have basically now exhausted the list of commonly used redstone bugs, can you please give me a build that uses none and behaves differently in 1.12 and 1.13 due to what you describe?

so
I now build this using 1 gametick signals. im guessing they are intended

https://streamable.com/ndivg
https://streamable.com/nu4sy

the problem is that normal piston now have the same behavior as described in "122911"

Fine, I just added a different contraption that uses NO bugs

While this new behavior may break existing contraptions, it actually sounds to me like a potentially useful new feature. We can now have finer control over how long a regular piston takes to push. Old machines can be redesigned with repeaters to compensate. Think of the ways we could use that to make machines faster. With all of the complaints about redstone features being taken away, we should cherish the few new ones we get.

This is actually a loss of feature because we used sticky pistons to control the time of extension and normal pistons for fixed timing. Now we lost one of the options. This just makes normal pistons the same as sticky piston block dropping a glazed terracotta.

@unknown, no you used MC-123217!
@unknown, can you please upload a structure file of the contraption in your last set of videos? The website you're using is really bad for pausing at a specific time, so I can't rebuild it from that.

In an idealized and, most importantly, mutable, potential intended future state where 108, 8328, 123217, 122911, and all other bugs have been resolved or had suitable alternative mechanics implemented, then this bug might be irrelevant. If that's the case, then the code that causes this "block teleportation" would be redundant anyway. However, we're not in this ideal future state, and this change in behavior breaks many builds.

It was my understanding, and even my experience working with Grum on trying to maintain sticky piston block event ordering, that the devs were committed to not breaking builds and maintaining 1.12 behavior as much as possible. If that is still true, then this should be looked at. The fix is probably not difficult. It's probably just a case of wrapping the line of code that clears the block entity in an "if (isSticky)" statement.

What's even more notable is that the clearing of that block entity probably exists intentionally to maintain the behavior of 122911, which, if you recall, was restored based on the same commitment to maintaining compatibility and not breaking builds. Even though Grum really dislikes that bug, he went out of his way to preserve it for us. Please do the same here.

If something is only buggy due to another bug or can only be tested once the other bug is fixed, then the report gets marked as blocked by the other report. So when the other bug gets fixed, this one gets looked into again and the report stays open until then.
Since I don't even know what the real problem here is, can you please tell me which report should get marked as blocking this report?

I think I understand. Keeping track of all of these inter-related things is quite the task. In that case, fixing this bug would be the most correct behavior possible now. The "teleportation" that is in place now would be the bug. Allow me to explain.

That this happens with sticky pistons is one aspect of the 122911 bug. Technically, it could be coded so that the block drop in 122911 happens without the "teleportation" aspect, but the way it presents in the code is that the act of teleporting the block is what sets the flag to drop the block in 1.12. So, both behaviors have always been discussed together and never separately. Both behaviors were removed early in the snapshots for 1.13, but Grum agreed to restore both behaviors shortly after.

So, for a sticky piston when a redstone pulse is cut off before the extension completes the following happens:

• The Block Entity for the piston head is cleared.

• A new Block Entity for the piston head for retraction is created.

• The Block Entity for the block being directly pushed (not any attached blocks in a structure) is cleared. This causes it to be converted back into a normal block in the target location immediately. 

• A flag is set that cancels the "pull" behavior of the sticky piston (the infamous block drop).

In 1.12, a regular piston doesn't perform the last two steps. In 1.13, the 3rd step, however, is being performed. This is what breaks existing builds.

If all of the other mentioned bugs were fixed, then the case of what to do when a piston is "short pulsed" would simply never come up. The clearing of the piston head Block Entity can be considered a work around for this special case that can happen now, and it's the bare minimum needed to handle it. So, asking for an example of a behavior change that doesn't depend on short pulses is an impossible task.

Therefore, there's no reason for this to block any other bugs. Restoring 1.12 behavior, in this case, is not something that needs to be undone later down the line.

I hope that helps clarify.

There is no "flag to drop the block", that's why it randomly broke in one snapshot and randomly came back in another. It is not intentionally implemented.
Grum also didn't "agree to restore the behaviour", it just happened when fixing other things. A direct quote from Grum from that report:

The piston dropping its block is not a feature. Nothing in the code supports it being a feature either, this is why when you do changes in other places in the code it suddenly stops working. The behavior from before the snapshot has been restored by fixing another bug (MC-122711). Do not expect the piston-dropping-a-block to be in the game forever without changes. If you need to drop the block, push a glazed_terracotta, you can only push the block and not pull it.

Do you include 2 gametick pulses in "short pulses"? Because they are normal things and if you can build something with this that reproduces it, that's good.

I didn't say this report should blocker another, but the other way around. If you currently can't find an example to reproduce this because of another bug, it's "MC-?????? blocks MC-133273".

Can we now please get back from the meta level and actually talk about the main topic again? Please give me something that reproduces the bug properly. If you know what KrasserTyp built and can rebuild it (I can't do it from the video, because the website pauses weirdly), please attach a structure file of that and I'll look into it. It looked like it would reproduce this without using another bug, but I'm not sure.

well the webside works fine for me, but i can upload it directly ofcourse