To explain a bit why this isn’t as desirable as it might seem: imagine I am using package A which imports NumPy 1.21, alongside package B which uses NumPy 1.16. I call A.load_data() which returns a NumPy array, then I pass it to B.process(arr). Either B thinks it hasn’t got a NumPy array at all (isinstance(arr, numpy.ndarray) is False), or it has an array that may have a different layout than its NumPy library expects (different attribute & method names at the Python level, different memory layout at the C level).
Being restricted to a single version of a library actually makes life much simpler: within a process, you can assume that a NumPy array is a NumPy array, and you can always pass it back to NumPy functions. The alternatives would be that either the NumPy developers need to plan for in-memory forwards & backwards compatibility - handling an array created by both older & newer versions of NumPy - or that code using NumPy has to keep track of types like ‘NumPy 1.21 array’ and convert between different variants of the same thing.
I’m using NumPy as an example, but this would affect any library which defines its own classes and allows them to be used from outside its own code.