Maintaining a part's launchID is critical to completing contracts that require a new vessel launched after accepting the contract. When KSP launches a new vessel (either from the VAB or via a construction mod such as Extraplanetary Launchpads), the current launchID is assigned to every part in the new vessel and then incremented. The contract system records the current launchID when a contract that requires a new vessel is accepted.

Parts placed in a container in the editor (VAB or SPH) have launchID = 0. The problem arises when launching the vessel: the vessel's parts are all set to the current launchID, but the item launchIDs are not set, so they remain at 0. Placing one of these items on a contract vessel will cause the contract system to think the vessel is older than the contract and thus the contract will never complete.

However, placing a part in a container in-flight seems to correctly preserve the part's launchID. This is good.

Previous versions of KIS would set 0 launchIDs to the container part's launchID when loading a vessel, but this workaround no longer works (and was inadequate anyway, as a save/load cycle was required, which most hard-mode players will not do).

Actually, this is more complicated than I thought initially. The launchID is saved in the items config node, and every stack in the inventory can have only one config. That said, if two items from different launches are stacked, one of them will lose the ID. This cannot be fixed without significant refactoring of the whole storage approach.

While true, this has always been the case (I noticed it with EL's survey stakes), so ensuring the launchID on a part taken out of storage is never 0 does not break anything and is an improvement. I would say that launchIDs getting lost on stacked items is a separate problem.