Aaron Rhodes

Since this bug happens even when the item command is not being spammed/run on repeat, but rather just when the command is used in general, it is a separate issue from the other bug report. The description should be updated to reflect that information to make it more clear that it's a separate issue despite the outcome of both being the same (ghost items being created).

Custom advancements being revoked here makes sense, since the developers naturally can't update, manage, and support those on their end. Because of the changes, those advancements become invalid until the individual updates them on their end, and any associated data (like who has earned the advancement) is naturally lost in the process (since to the game that advancement no longer exists or can't be found). Really don't see anything they could possibly do to fix that.

Where is your proof/evidence that it wasn't implemented as intended? It already appears clear that it was implemented correctly/as they intended, because everything related here has various contexts that they work under and ones that they do not. Just because you or others can't personally use it how you want to does not make it a bug or unintended. It's use first and foremost was only for the given contexts that it currently works with. This is not a valid bug report, it is a feature request.

The first part of it is entirely normal. When you open the inventory, you naturally stop sneaking because the menu you're in takes priority on controls (in this case the shift key serving a different function while in the inventory, and other normal controls being locked while in the inventory as well). The last part is debatable since it could be seen as normal behavior (needs an extra press for it to detect the key being used again afterward). So overall the only potential bug/cause here is that the game doesn't do another check for held keys when GUIs are closed, which may or may not be intended.

I've explained why in an earlier comment. Buried treasure maps check over a large area of chunks to find the nearest buried treasure, but it is set to only search out to a certain amount (this is why the freeze stops after awhile, if no buried treasure is found within range). The lag and freezing happens because searching over a massive area of chunks is extremely resource intensive, slowing the process to a crawl. If no treasure is found in range, it results in a normal non-filled map with either the translated name or the translation key. I provided a bunch of other info in my previous comment as well.

It is not a bug, it doesn't work because it is missing the correct context in that use case. That predicate is intended to be used in loot tables where that necessary context is provided. More specifically, the missing context in selector arguments is "Damage Source", which is the source of damage that caused the entity to die. Since target selectors can't target a dead entity due to it not existing, it's impossible for that context to exist for target selectors to work with, causing the predicate/check to fail by design.

The item modifier wiki page provides some valuable information on the topic. Under the exploration_map item modifier section, there is a search_radius parameter that reads:
"search_radius: The size, in chunks, of the area to search for structures. The area checked is square, not circular. Radius 0 causes only the current chunk to be searched, radius 1 causes the current chunk and eight adjacent chunks to be searched, and so on. Defaults to 50."
Using /locate can give the absolute distance to structures on the xz plane, and since the area checked by the map is square and not circular, 2 structures that are the same or similar distances away won't necessarily both be within that square area. This should help clarify what someone else mentioned in an earlier comment where a structure that was closer was not within the search area compared to one that was further away.

With the default search radius being 50 chunks, that's going to be roughly between 800 blocks out (if going out to the edges of the square search area) and 1131 blocks (if going out toward the corners of the square search area).

If no matching structure exists within that square search area (that is, it searches the maximum allotted area and doesn't find anything), it results in this bug. You can also experience a lot of lag if the structure is far enough out, since the process becomes extremely resource intensive at that point, and that's also the reason there is a cutoff point in the first place, which in turn causes this bug.

The explorer map wiki page also has some relevant info:
Name: The name the map is given. In this case, they are localized strings: either {"translate":"filled_map.monument"}, {"translate":"filled_map.mansion"} or {"translate":"filled_map.buried_treasure"}

I seem to recall some situations where the name of the item becomes "filled_map.buried_treasure", and the translation key would be why.

I second reopening it, namely because the setworldspawn command includes a y value as a parameter, implying that that value will actually be used. If it doesn't get used and isn't intended to be, then it should not exist as a parameter as to not cause confusion and to reflect the intended behavior. And setting the spawn radius to 0 also implies that being spawned anywhere outside a radius of 0 in 3D space (that is, the y included) is not intentional. The natural world spawn behavior is of course well known and is not what the bug is about (since this is artificially setting a world spawn with commands).

If that really is the case, then that would make it an invalid bug report due to modified/3rd party content being involved. Although it could also only be optifine causing issues on your end and might not be the same cause for everyone else (in which case it would still be a valid report).

We do have some information from the screenshot, that optifine is being used (meaning this is potentially not even a valid report due to not being a purely vanilla environment).

How exactly is this a duplicate if the other report was made almost a year later than this one? That isn't how duplicates are supposed to be handled. A duplicate is a report that is made when one already exists, making the other report the duplicate, not this one. I've seen a lot of other false/wrong resolutions used by the moderators and Mojang before, and it seems like things are handled very arbitrarily here without any apparent reason or explanation.

It should be made more clear what the actual bug is, as this report seems a bit too ambiguous. Should the totem be showing up along with the particles, or should neither the totem nor the particles show up? It sounds like you believe the bug is the former, but the totem not appearing suggests that the bug is actually the latter.

Considering you don't even have physical contact with those blocks yet their properties (which rely on physical contact) still apply, it's a no-brainer that it was a bug to begin with. The only reason I can see for this being intended is if the code is set to detect a player in the block space above those blocks, as opposed to being physically on top of the block itself. In that sense the code would be working exactly as it was designed to, despite it not being an intuitive or reasonable design.

"They're neutral rather than passive, so they still despawn when the difficulty is set to peaceful"

Piglins are neutral as well (primarily hostile too), so what logic is there to them becoming passive, especially when the zombified version despawns as expected?

Emeralds aren't a progression based item though, nor is gold (gold is a side ore that's not necessary to the progression). Both wood and stone are progression based materials, but they aren't used. It's actually based on metals and gems, which is what the logic for including netherite is.

Why are you on the bug tracker if you're reporting something you don't think is a bug? That's just nonsense and wastes their time having to deal with a potentially invalid report.

This is WAI. As explained by HelenAngel on the minecraft discord, there are no plans to add a crawling animation or to expand on "crawling" any further. It only exists to prevent unintended suffocation in 1 block spaces due to gliding, swimming, etc. into them. As there is no clear intent from them on expanding upon it or adding a proper animation, that makes the current setup intentional, not a bug.

That is not how bugs are handled or treated (that much is basically common sense). There are many bugs that have been ongoing for years, that doesn't make them any less of a bug nor does it change the stance on fixing them.

Affects 1.15 Pre-Release 5

Seems this can be closed with the changes that were just made in 19w46a (all foods can be eaten in creative mode).