1. Using a command block to create an item with colored display name (I hope the command is correct / uses the regular format used for colored items): "give blablubbabc minecraft:stone{"display":{"Name":"[ {\"text\":\"Stone\",\"color\":\"gold\"}

   ]"}} 64"

1. A plugin uses Bukkit's item serialization to store this item in a config file. The colored display name will be stored using the legacy color code: "§6Stone"
2. The plugin loads the item again.
3. The deserialized item will no longer match the previously serialized item. The display name will also no longer be in italic font (see screenshot:http://prntscr.com/o0gcp4 ).

Attached is a plugin for testing this: When holding an item in hand and interacting with air, it will save the item. It will also compare the item to the item currently in the offhand slot. When holding no item in hand, it will load the item from the config.

 
Edit: With MC 1.16 this issue seems to also affect items with very simple display names and lore, even if they don't contain any color/formatting.

Example:

/give @p minecraft:lime_dye{display:{Name:'{"text":"Bla"}'}} 1

This item will get converted to an item with tag

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

during item de/serialization.

Edit: A related issue is that with MC 1.16 Spigot has made some changes to how they convert between legacy text and Minecraft's text component format. This change of internal representation results in newly created items (eg. created via Bukkit's API and using ItemMeta#setDisplayName(String)) to no longer stack with items which have been created in the same way in a previous version of Spigot.

Edit: I created a separate issue for the change in Spigot's item data format: https://hub.spigotmc.org/jira/browse/SPIGOT-5964

Edit: One workaround seems to be to use legacy color codes in the give command, such as for example:

give @p minecraft:emerald{display:{Name:"{\"text\":\"\\u00A7a\\u00A7oEmerald Name\"}",Lore:["{\"text\":\"\\u00A76\\u00A7oLore\"}"]}} 1

Edit: Actually, this 'workaround' does not fully work (anymore?). It seems that the escape sequence 

\\u00A7

is not getting converted to the "§" character immediately. See https://prnt.sc/t3vms3

There are some situations in which this conversion occurs: CraftBukkit triggers this 'conversion' in cases such as when the item is getting serialized and deserialized or when handling certain events such as when the item is getting dragged around inside the inventory.
In vanilla Minecraft I have only found one occasion which triggers this conversion and that is specific to enchanted books getting disenchanted inside a grindstone. In other situations the item's display name will either remain as it was (and keep using 

\\u00A7

internally), or break (eg. when repairing these items inside an anvil without renaming them, see https://bugs.mojang.com/browse/MC-1443 (Mojang considers this 'as intended' since there is no need for them to support these legacy formatting codes anywhere inside the vanilla game)).

The items which got 'converted' will not match (ItemStack#isSimilar) any items which did not yet get converted.
So the current situation seems to be that Bukkit does not properly support items with non-legacy colors (eg. data not getting persisted correctly), while Minecraft does not properly support items with legacy color codes (see for example the issue linked above about repairing these items in anvils).

Offtopic: I might be wrong about this, but has there be a change regarding whether empty inventory slots return null or an AIR item? I know that minecraft uses the 'empty' item (of type air) for these slots internally, I just thought to remember that bukkit kept returning null for these anyways. During my testing I noticed that these slots return empty AIR items now.