I originally mentioned this issue as part of https://hub.spigotmc.org/jira/browse/SPIGOT-5063. However, even though the issues are related, a fix for one of these issues won't necessarily also resolve the other issue. So I moved this into a separate ticket.

During the update for MC 1.16 Spigot has made some changes to how they convert from legacy item display names and lore to Minecraft text component format.

Eg. an item which previously had the internal nbt data

{display:{Name:'{"text":"Bla"}'}}

will now be created by Spigot with the the data

{display: {Name: '{"extra":[{"text":"Bla"}],"text":""}}}

If color codes are involved the change between Spigot versions is as follows:

{display:{Name:'{"text":"§cBla"}'}}

This becomes:

{"extra":[{"bold":false,"italic":false,"underlined":false,"strikethrough":false,"obfuscated":false,"color":"red","text":"Bla"}],"text":""}

This issue can be encountered whenever a plugin creates an ItemStack via the Bukkit API (eg. using ItemMeta#setDisplayName), or when a plugin deserializes ItemStacks from a configuration file (during deserialization CraftBukkit invokes CraftMetaItem#setDisplayName as well to convert from the stored legacy text to Minecraft text components).

The actual issue with this change in internal text representation is now that items created by plugins on previous server versions will not match items created on Spigot 1.16 (i.e. ItemStack#isSimilar(ItemStack) fails for these items). Since minecraft itself considers these items to be different as well, they will also not stack.

Edit: This new text representation is also an issue with blocks picked up in creative mode. Minecraft will add a lore to the picked up ItemStacks with text

'{"text":"(+NBT)"}'

After a plugin has serialized and then deserializes the ItemStack to/from a config the text representation of that lore has changed to

{{'{"extra":[{"text":"(+NBT)"}],"text":""}'}}

, making it no longer stack with any original items (reference: http://prntscr.com/tf4xba).

I am not completely sure what a fix for this could look like.

• One could look into somehow reverting this change in representation (i.e. try to make the conversion produce nbt which more closely matches the previous data format). For simple texts this could mean avoiding creating the unneccessary extra tag and producing the more compact representation, similar to before. This would also mean that ItemStacks created by users via Minecraft mechanisms (eg. give commands, loottables, etc.) are more likely match Spigot's internal data format and therefore compatible.
  However, avoiding legacy color codes inside the produced components is probably a good change. Nevetheless, for the same reason as above, the produced component text could probably be more compact by only outputting those entries that are actually needed.
• A different solution could be to automatically convert items to Spigot's data format. However, this would need to happen within the Minecraft server itself for any items that have already been created in the past.
  Paper seems to have recently made some change to do something like this: https://github.com/PaperMC/Paper/pull/3741/files
  However, this seems to only convert the item data if it contains legacy color codes, but the issues also affects items without color codes as shown above.
  However, since this would then affect all ItemStacks, a potential issue with this could be incompatibilities with any vanilla setup/contraption (eg. involving command blocks or similar) which somehow check for items with specific nbt data / expect the items produced via Minecraft mechanisms to keep there exact internal representation.
• A combination of these two points could be to:
  • Create a more compact json representation for plain text without color codes. Maybe it is also possible to create a more compact representation for text with colors, but I am currently not sure if there is maybe a reason to produce this verbose output.
  • Convert any minecraft itemstacks which contain legacy color codes. Any items created by minecraft or via minecraft mechanisms will then not be affected by this Spigot conversion (since those items are not expected to contain legacy color codes).
  • However, since Spigot 1.16 has been out for a while now there may already be quite a few items with text in the verbose format (using the extra tag and an empty text tag at the end) which don't use colors. It might make sense to also convert any of these items (if this pattern is matched). It is unlikely that players have explicitly created items in this verbose format, so the impact on items not created by Spigot should be limited.