handling different required package versions
You have a couple of options these are the only ones I can think of:

fork (sorry but this may be the easiest/ quickest),
wait for a new version for the older package, or
change it to not use zipped eggs (I don't really understand this though).
[EDIT] could you potentially trick one into thinking that it is using its version. I don't know the specifics, but from my understanding you could use a virtual machine.

There could be others that I don't know (it actually probable) but that is all I could think of hopefully you find a solution though!
I (thankfully) never ran into this before, and (sadly) just did.
My app now imports 2 packages, which each import the requests library.  The two authors have pegged the version of requests to different versions.  One wants 2.1.0 , the other wants 2.3.0.
Automated tests appear to pass on both.  My app appears to function perfectly on both.
My app won't start, however, because of the requirements.  From what I can understand on my development environment, it's because of the version number being pegged in a requirements.txt file.   [ In dev we have PasteDeploy + Waitress, an exception is raised in PasteDeploy; in production we have uwsgi ]
The only ways I can think of handling this, is to:

fork the projects
change the system to not use zipped eggs, and run a patch.

both are going to be a hassle to maintain, and add a lot of complexity to the build/deploy process. 
does anyone have other suggestions?