Are you positive its a specific issue just with map # 0 ?

It's not specific to map 0 as such. What happens is that when you right click an empty map the client goes, "ah, a map is being added, empty maps - 1, add a new map, uh, oh, maybe... 0?" and adds a "Map #0" to the inventory. That happens (visibly) before HandlePacketUseItem even gets called on the server. The server then does the right thing, allocates a new map number, creates the item, adds it to the inventory and sends the client a SetSlot to tell it what happened. But the client's predicted map 0 went "somewhere" - maybe stacked with another "Map #0", maybe into an empty slot. So we need to tell the client what SHOULD be in any slot we know is either empty or has one or more "Map #0"s. One of them is wrong on the client but we don't know which one :-(

The 1.13 problem, ah, "enhances" that because if the client doesn't get the map number in item NBT data it thinks every map is #0 - even the ones correctly added by the server. Even more entertaining is that if you don't parse NBT on item data received by HandlePacketCreativeAction then the as soon as you open the inventory in creative mode the server becomes persuaded that all your maps are #0 too! Passing NBT backwards and forwards probably also fixes, or at least heps with, other issues with damage, repair costs, custom name and other stuff.

Interesting times, huh?