It comes up with apis that deal with data storage or IPC concerns.

You might need a handler for both versions if you have customers that use the old api and ones that use the new one. Or different departments of the same customer.

Or if you dodge that bullet but have to write a custom migration tool to get data from the old version and cook it to go into the new one. Half of the code is read only and the other write mostly but they still have to coexist if you do anything more complex than a backup/restore script.

If the newer version of some library has some breaking changes, you can migrate bit by bit instead of doing it all in one go.

If this is the only motivation for multiple dependency versions in the same compilation unit (crate), I'm not convinced. You would be trading off the simplicity of each crate specifying a range of acceptable dependency versions for specifying `N` ranges of acceptable dependencies, and requiring one of each. Much better to enforce one version per compilation unit, and if you want to get complex with your dependencies, then break your project into multiple compilation units.