I have item 1:
/give @s chorus_fruit_popped{display:{Name:"{\"italic\":false,\"color\":\"dark_red\",\"text\":\"Ashen Talisman\"}"}}And item 2:
/give @s chorus_fruit_popped{display:{Name:"{\"color\":\"dark_red\",\"text\":\"Ashen Talisman\",\"italic\":false}"}}These should be the same item, as they have all the same tags. However, since the name object is stored in a string, the equivalency between the name objects is determined to be unequal, and so these two items will not stack with each other, even though they are functionally identical.
This is not only a problem when trying to stack items obtained from 2 different location (e.g. a function and a loot table), it is also a problem when checking the name of an item in the possession of an entity, as you now must know the entire name object (The order of which is undefined) instead of just the name, as was the case pre-1.13.
Linked issues
is duplicated by 7
MC-166979
Custom Items created through Loot Tables are "incompatible" (can't stack) with the exact same item created through commands
Resolved
MC-169612
minor bug with /give
Resolved
MC-175743
NBT Text Field Order Randomized
Resolved
MC-179998
Items With Same Lore Won't Stack
Resolved
MC-198089
NBT rename/lore text missaved
Resolved
Comments 5
So this has now been labelled "Won't Fix"? Oh boy.
I've been waiting on this getting addressed for 3 and a half months now, so thank you for at least making your intentions clear. I should also say that I wasn't expecting this bug to be fixed anytime soon (Although I was hoping it would be), as a proper fix would require a rather major refactor of the way in which JSON is parsed and used throughout the game as a whole, just for something that many people would see as a "minor inconvenience".
I've been developing a custom map for 4 and a half years now. Naturally, I want to find ways to make development easier and to speed it up, avoid bugs due to inconsistencies, etc. So I've built a strings system that allows me to centralize all occurrences of the same text, and allows me to change it all throughout the data pack by just changing it once inside the strings. This has been incredibly useful, and has allowed me to do other useful things like having a loot table and give function for each custom item. 1.13 added a "set_name" function to loot tables, which is rendered completely useless due to this bug. The order of the keys in the generated JSON object are arbitrary by definition, so I can't know what the Name string will actually look like. Therefore, it is quite unlikely to be the same as the one created by the function (Which must be hardcoded, not generated), and I won't know what to look for in a command looking for a player holding that item. For instance, I cannot do "say @a[nbt={SelectedItem:{display:{Name:"{\"text\":\"stick\"}"}}}]" if the item was obtained through a loot table that uses the set_name function. On top of which, that is a fat wall of brackets, backslashes and quotes. When you have to test for dozens or hundreds of items all in different places, the bug is no longer a minor inconvenience. It's a gigantic pain in the butt.
I don't expect this to be fixed soon. Heck, I don't even know that I want it to be fixed soon (Opportunity cost and all). What I want is the "Won't Fix" resolution removed. Won't fix in the near future, sure, but this does need to be fixed eventually. Labelling it "Won't Fix" is equivalently to sweeping it under the rug and ignoring it until it comes back to bite you. This is a problem and it needs to be addressed, especially since it may get worse in the future.
The order of the keys in the generated JSON object are arbitrary by definition, so I can't know what the Name string will actually look like.
Sounds like that's the bug you should be reporting. Do we have a ticket for this one yet?
That's not a bug though. JSON objects are, by definition
an unordered collection of name-value pairs
The issue is that the unordered name object is stored in a string, which is an ordered list of characters. That is a workaround to avoid quoting object keys, but creates this bug.
I agree that this is troublesome and definitely not a simple fix. To my understanding, all item NBT is stored as literal NBT in-memory, in contrast to, e.g. entities, which only load/save their NBT representations when necessary. As such, item display names can't exist as anything other than a string (specifically an NBT string).
Even if that weren't the case, you'd still have trouble for mapmaking, as it would be serialized as one and you'd have the exact same issue with comparing strings whose content order is undefined. For maps in particular though, checking for an item by name is usually a mistake unless you want to... check if the player renamed something in an anvil, I guess?
By the very nature of the "NBT in memory" detail, you can set and compare any arbitrary NBT you'd like to identify your items instead of relying on the name.
Given that name objects are currently escaped inside strings to avoid the issue with text objects requiring quoted keys while all other forms of json in the game don't allow quoted keys, one possible fix for this issue may be to make it optional whether keys are quoted or not. That is, any json object will either have all keys quoted or no keys quoted. Then you can make the CustomName tag a text object, and any json object that uses CustomName or any other text object will have to have quoted keys in order to be parsed, but any json object that doesn't contain a text object won't. This could solve this issue (As well as potential future compatibility issues), whilst also easing the transition to quoted keys, because most existing cases won't need to be changed, and future ones can be written with/require quoted keys.