Short story: In runtime, if ever I select my player in the hierarchy all of the null InventorySlot.Item class objects in my player inventory get magically initialized no longer returning null.

Long story: Clicking on the player GameObject causes the problem… that right there has me stumbled. The list in question:

[HideInInspector] public List<InventorySlot> equipmentSlot;

is quite simply a list of a class that stores some enums and an itemAmount int, nothing fancy. I have checked all references to it project wide, I have added Debugs into everything that goes anywhere near it, and ONLY when I click on the player GameObject in the hierarchy does the problem occur.

The problem: when the game starts the List is initialized setting the Item variable in each InventorySlot to null, because there are no items in our inventory yet. I can confirm that with Debugs in runtime, they are null. Then I click on the player GameObject in the hierarchy, and call the same Debug, now the Item is not null and returns as an initialized Item, but of course all of it’s variables are empty and now the game doesn’t know what to do with it.

How does that make any sense?? Monobehaviors respond to in editor selection some way that I don’t know about?

The Count of the List remains unchanged. The order of the list remains unchanged. The InventorySlots that have things in them, or in other words are not null, go unaffected. The InventorySlots that are null somehow are magically assigned an empty Item.

The InventorySlot class doesn’t even default to an initialized Item, it loads them as null:

public class InventorySlot {

	public int slotNumber = -1;
	public int itemAmount = 0;
	public Item item = null;
	public InventorySlotTypes slotType = InventorySlotTypes.Null;

}

I can pause, click on everything else in the scene, unpause no problems. Pause, click on the player, deselect the player, unpause and the inventory is broken. By broken I mean empty slots are supposed show their Item as null, but now they are all initialized somehow.

Would never happen to a player in a real build sure, ya I could hack around it to find empty items and reset them as null, but what in the heck is going on??

There’s only one reason I can think of this is happening. When writing custom inspectors, whenever a gameobject is selected, a MonoBehaviours serialized values get read and written to, depending on what code is used. maybe the same is happening for classes that do not have a custom inspector. List<InventorySlot> is public, therefore serialized for the inspector. For the serialization, null does not exist and an actual instance information is saved. Maybe, without using a custom inspector, the default is just that, write the serialized values to the actual gameobject.
You should be able to check that by simply adding the NonSerialized attribute in addition to the HideInInspector attribute, like so [HideInInspector, NonSerialized]

Thank you @hexagonius
NonSerialized did in fact prevent the problem
Haven’t 100% wrapped my head around the answer and all possible scenarios, but your explanation makes sense. Thank you for the enlightenment.