So the issue here is that these aren't cargo bays, they're fixed values of 'cargo'. So it's not saying that the unit has x cargo capacity, it's saying that the unit has y cargo.

I suspect this is a legacy decision, but @HammerGS might be able to weigh in as to how best to handle this. Because quite rightfully, players are going to see this and mentally parse it as cargo capacity.

To put my two cents in; the unit obviously isn't carrying around a black box that is labelled 'cargo' - it seems that it could only function as a container that could be reasonably filled, used to transport, and then emptied. I think it definitely should count as cargo capacity for the purposes of Mekhq/stratcon if nothing else.

This issue is one of internals - I'm inclined to agree with you - but this value appears to be just stored as a String and not as a definitive Part we can directly interact with. Meaning any parsing would need to be String-based -- i.e. checking whether the String Cargo ( appears in the parts list (if it appears in that list at all, I'm making the assumption it does). String comparison is one of, if not the, weakest form of comparison because if the String ever changes we'd need to go in and fix any instance where it's being parsed.

Not to mention we'd need to parse every part on the unit to find the 'cargo' parts.

I went ahead and implemented String comparison. It's not idea, but I strongly agree that these units should correctly report their cargo capacity and short of introducing an entirely new Part type (and then making that backwards compatible) I'm failing to spy a better alternative.