It is not tied to shallow copies, it is tied to new packet construction and this is what is expected. There is clearly more going on here than what you are reporting.

At the very least, we need to better specify what the semantics are of Uid.  We may also want to consider whether or how we include it in the ascii traces, to avoid confusion.  There is some history to deal with, in that these uids have been used in ns-2 and other simulators to track notional packets.  A user may not understand from the current doxygen that the constructor may also be called internally in the stack for various reasons.

The problem is that code segments may use new packet construction as a mechanism to do things within a model, but the black box behavior is such that new "missing" packets are absent from the traces.  e.g. point-to-point-net-device.cc:209

However, it is not trivial to try to make this UID correspond to notions of actual packet counts, however.  What should the packet uids be when packet is sent broadcast over shared media, or when fragmentation occurs?

Perhaps the best way to handle this for now is to better document somewhere the fact that pkt-uid is an internal uid and cannot be counted on to provide an accurate counter of how many "simulated packets" of a particular protocol are in the system, and that if a user wants that, he or she may choose to look at IP id or other counters at other layers. 

clarified in doxygen with changeset 1782.  Will add something to the manual when the packet chapter is revised.