Here are a couple trees to bark up:
First, it kinda sounds odd that a GM would say they have some command to 'see' the item exists, yet they cannot do anything to it. Maybe they misinterpreted the 1 return value of container.item_count as meaning there was an item in the container (item_count always returns 1 for the container itself, when empty). But if they had a command that was iterating through the items in the container, it seems that they would have tried creating a command at some point to let them SELECT an item and have it moved to their backpack, or to the ground, or something... it seems like waiting for an item to decay to 'fix' a bug is a pretty kindergarten solution :razz: At least you're looking to do more than that, so kudos there
Next, though; If this item was truly in the container, and could not have been accessed by a script at all, then when that container decayed, the item would NOT have been dropped to the floor. It would have been destroyed right along with its container. That's why I asked the above; Why didn't they just make a command to list the items in a container, and draw one out?
Because if the container decaying fixed this, I guarantee I know what was happening: They had a fairly commonly implemented script (which I do not use myself) that runs when a container is destroyed - the script moves every top-level item from the container to the ground where the container was. Only a script would do that - the core does NOT; it deletes items from containers that it is deleting.
But here's another tree to bark up: Maybe this 'bug' actually has something to do with what the items are. There are some items which simply will not display properly in most containers. You drop it in, and in it goes... but you'll never see it. It'll show up in EnumerateItemsInContainer(), etc... but no matter what you do, you'll never 'see' the item in the container.
But put that same item on the ground, and viola'; There it is! An example of an item to which this applies is a hair object, for example. Other items will show as 'No Draw' or some other invalid graphic, unless they are in a certain container (such as game pieces). Perhaps the bug is actually related to the ITEM, then - not the container.
It could also be that an item's graphic is being changed to something invalid when being inserted into the container, causing the same effect. For example, we have an equippable 'Death Shroud' on our shard. However, for it to work so that people can actually see it in their backpack, the graphic needs to be changed when it is unequipped. Otherwise, it would be in their backpack, but completely not visible. Dropped into a 'secure' container, it would seem to have the same 'bug' as here, when all along, the problem is with the item itself.
The fact that this seems to happen to items in 'secures' also really strongly suggests to me that this is a script bug; Since secures really are a completely script-based feature, something in the process of making an item a secure must also be causing this to happen to items. The fact that it has happened to non-secured containers too *may* only mean that those containers used to be 'secures', but were released improperly such that they still have the OnInsert/CanInsert or other such related scripts running, thereby still causing the bug.
I would definitely try to remember or see if there is any similarity in the types of items this has happened to. Perhaps there is some similar script to the one I mentioned for our Death Shroud that is being 'broken' somehow by script that runs on the secures On/CanInsert.