In V3, this wasn't a problem because all the classes required for verification were available to transactions via the system class loader, even if they were not attached to the transaction itself. Whilst this is not the intended way for Corda to work, no-one ran into any issues because all the classes were available via the system class loader. This worked even for CorDapp dependencies where the states-and-contracts.jar depended upon a class in another jar.
In Corda V4, there is a different scheme for class loading classes required for transaction verification: the attachment class loader. All classes needed for verifying the transaction are required to be on the class path of the attachments class loader. This is possible for V4 transactions because if needed developers can just manually add the jars via TransactionBuilder.addAttachment.
However, when V3 transactions were created, the old class loading rules applied so it's unlikely that developers actually added all the jars to their transactions manually. As such, it is highly likely that if CorDapp developers have arranged their states-and-contracts jar such that it depends on classes in another jar, then transactions using the states-and-contracts jar cannot be verified in Corda V4 due to the depended upon classes in the other jar being missing.
We cannot retrospectively add the required attachments to the transactions as they are immutable. Therefore, the platform needs some means to load classes available in the cordapp class loader to fill the missing gaps for the attachment class loader. has more info!