Usually I would write:
"This is no discussion forum blabla hop over to Mojira's Subreddit blabla, mods will get angry bla."
However, considering this bugpost was resolved as a duplicate of another bugpost which in turn is set as duplicate of this one [MC-200782] I hope Mojang devs would be so kind to look into this again and give us an answer what is going on behind the scenes, as resolving a duplicated bugpost with the duplicate is quite confusing and evidently upsetting to the community.
The fact that the mods here didn't yet intervene is quite strange, considering many other cases I witnessed where they did.
Currently have to assume the actual reason is something Mojang mustn't discuss publicly, or that they haven't discussed this issue yet internally and/or with Microsoft, or don't know how to phrase matters (yet) publicly.
@unknown In which MCJE version did this occur for you?
Are you in Vanilla?
@unknown As for "SpergOut" at least, that's an IGN which is offensive, hence no one should get access to it anyway.
No idea what the other account names that are "soft-blocked" are like, but I hope nothing similar.
@unknown Could you please review this bugpost again?
Bad Actors Servers can hypothetically get Players banned.
If the Player would notice at all that their messages have been tampered with, they would, if they appealed against said ban, have no chance to prove the Server was the actual culprit.
That can't be "WaI"?
It's not up to shrewd, skillful, biased (paid by Microsoft) legal people to determine whether or not something constitutes a violation against e.g. GDPR.
Generally speaking, legal loopholes, BigTech (not only, but also Microsoft) lobby work incl. BigTech stalling GDPR regulation and more exist, data rights protectors know and complain about that.
It's up to those making those regulations, laws, to decide whether or not Microsoft violates e.g. GDPR, be it regarding telemetry or other instances.
And, generally speaking, let me state that even if something is legal, it doesn't necessarily make it right.
@unknown People likely got different methods, mods to see HorseStats are one way, of course those usually don't work in snapshots.
What you could do is to summon horses with fix specific stats, breed them, and look into the foles' outcomes, e.g. manually via data get entity, or you create/use a datapack which would show you horses' stats.
With that approach, you would amass enough values to be somewhat sure that the Status Quo is still the same as described in the bugpost.
That being said, as long as nothing in the code itself regarding Horses would be changed, the way a fole's stats' outcome is calculated by the game should logically usually always remain the same.
@unknown In case you migrated, use either current OptiFine 1.18.2_HD_U_H7 here to patch the original launcher, there's a telemetry option in Optifine now you can toggle off, explained here.
Alternatively, use PolyMC, available here; it doesn't send telemetry by default.
Edit: This solely disables the telemetry sent by the Minecraft client, it does not disable the telemetry sent from what you're doing within your XBOX account itself, nor does it disable the original launcher's telemetry sent. If you close your launcher, it's still not really closed. Shoot it down in the task manager.
If anything regarding anything related to this topic will change someday and I'm still around, find me, as I'll have everyone know, as soon as I do.
@unknown Seems logical anything causing servers to crash to be seen as issue, no matter the effort needed.
Update suppression was a toy opening up new possibilities, I can get where you come from.
I also dislike some changes. If it were after me e.g. bedrock breaking in full Vanilla (dragon eggs/lazy chunks) should also still be a thing, even though it's quite easy to do. I'm also all for sand duping at this point in time.
But if we continue to discuss without bringing in something substantial to your bugpost here, the moderators are going to warn us that this is not a discussion forum and might shadowban our comments.
@unknown Update suppression in this form was an exploit which allowed you to crash servers, whereas reversed update order changes behaviour of Redstone and hence very much indeed sounds like it could be a valid issue and thus bugpost.
Both were caused by the same change, however, they are two different, distinct consequences, caused by this change.
Reversed update order / update suppression no longer working should be two distinct bugposts.
Going by what this type of update suppression caused, this seems to be most definitely "Works as intended".
Apparently confirmed for 1.17.1, see MC-240815 which seems to duplicate this bugpost here.
Note that with the setup in linked bugpost, several blocks get ghosted.
Must be ghostblocks, see e.g. MC-172880.
@unknown, if you go out of the world and relog, are all the "duplicated" blocks also gone?
Try also rightclicking those blocks, do they vanish upon rightclick as well?
@unknown Is this "Won't fix" a: "might fix itself later, as soon as we overhauled the whole GUI system" (which is what I've heard about as general potential future step, but not currently), or is it a true "nope, we're very certain right now that we'll always use the same GUIs for some block entities"?
If so, what's the reasoning behind this?
@unknown "Throwing Pearls through portal does nothing" seems usually to be the case if there are no blocks behind the portal, which OP had in their setup though.
Aside from that, iirc Pearls should port you also without blocks behind the Portal.
In Creativemode, Pearls insta-teleport you, OW>Hell and vice versa.
I still can reproduce some of the described behaviour, e.g. tested in 1.17.1 Vanilla:
Player can port through or rather into blocks that are directly behind the portal, if they are, like OP set it up, stairs and you throw Pearls into stairgaps/"holes", potentially in a specific angle (didn't have time to reproduce reliably).
If Player throws Enderpearl against another area other than stairgap, Player "collides" against the blocks behind the Portal, no matter if stairs or fullblocks.
In some occasions, Pearls do travel from OW to Hell without porting you though, likely as Hell is not loaded (haven't tested with 2nd Player loading Hell Portal chunk); as soon as you enter Hell (and thus load it), those Pearls port you within Hell.
I couldn't reproduce the biggest oddity OP showed in https://www.youtube.com/watch?v=uIjO-Un4SWY regarding exact coordinates of Nether Portal in the Overworld, instead of the actual Overworld Nether Portal, but that doesn't mean there couldn't be this or other things that are to my knowledge not WaI, considering I didn't test for very long.
Maybe it would help to change this bugpost's description accordingly to the behaviour in the current version, as this bugpost wasn't updated since19w03c, so maybe some of the described/shown behaviour doesn't exist anymore right now.
Hence describing what for current irregularities are observed, and new deviations ould be added as soon as they would be maybe observed.
Plus a description how the actual expected/intended Pearl-Portal-mechanic is supposed to be.
In case @unknown won't be reinstated as reporter and a reporter is needed, I hereby volunteer.