Is there a name for the code smell where we add different types of objects to a list or array instead of defining a new data structure? [closed]

I think the situation you described is a special case of a more general phenomenon I have seen several times: abusing some loosely typed container for creating and managing data records which actually deserve an abstraction on their own. This does not always come along in form of a list of objects, but also in form of dictionaries, string lists, tuples and sometimes just pairs or triples of variables which are passed around together from one method to another.

To clean up such mess, one has to introduce a type or class, give it an appropriate name, then introduce some member variables, give them appropriate names, too, and then think about further steps like moving parts of the code into methods of that newly created class. I guess finding a good name is often what stops people from doing this at first place, naming things well is one of hardest problems in Computer science.

Is there a specific, broadly accepted name for this kind of "code smell"? I honestly don't know, I would probably call it a "missing abstraction". However, the different refactorings for cleaning up such code have names in Fowler's refactoring catalog. The most suitable ones for fighting the described phenomenon (like "Extract class" or "Encapsulate Record", or "Combine Functions into Class") are listed in the encapsulation section of that catalog. In the long run, I guess the names of these ways to improve code will probably be more useful than any names for "bad" code.

It might not be a code smell but it might lead to code smells.

If we think of an array as construct that groups items together, books[] or movies[] being simple examples, then is there anything common about the objects and why they are stored in the same array or group? As mentioned by other it might indicate a common interface. IReadable or IWatchable.

The name is lack of type safety. You toss in a bunch of objects and leave it up to the consumer of the objects to figure out what they really are and cast them back to their subtypes. Which can go wrong at runtime. You would rather have some verification at compile time.

It is not necessarily bad to have different types in the same collection but you would expect some interface or common base type (with polymorphism) to go with it so they can be treated as one type.