I've been building an installer for the Salesforce.com Foundation's upcoming release of NPSP 3.0 which can effectively handle installation/upgrade of dependent managed packages as well as bundles of metadata in a zip file (via a url). This definitely has made it a lot easier to deploy dependent managed packages along with unpackaged code which doesn't play nicely in a managed package. For example, NPSP 3.0 consists of 6 managed packages and 2 unpackaged bundles of metadata.
You can configure the dependencies for each individual version. We have versions setup automatically via a python script run by Jenkins after a new beta package or production package has passed testing.
The application uses oauth to the target org to do the deployments and will determine if it needs to install, upgrade, or uninstall/install (downgrade or beta "upgrade"). You can also set conditions based on metadata in the target org such as "deploy this package if there are no record types on opportunity".
However, it's definitely not without limits:
It's not a mechanism for copying code between multiple packages, though I'm not sure that's the right approach for code re-use anyhow.
It doesn't handle push upgrades of the unpackaged metadata bundles though you could send users to the installer app again to get the updated bundles installed in their orgs.
The whole project is up on Github at https://github.com/SalesforceFoundation/mrbelvedere and the installer related code is in the mpinstaller subdirectory. I'll be doing more work soon to make it more generic (i.e. strip out the Foundation branded theme) and document the setup process. The running instance of the installer is at https://mrbelvedere.salesforcefoundation.org/mpinstaller/npsp/beta if you want to try it against a fresh DE org.
Another option is to use ant to control the dependencies. I've built ant targets that handle the install/upgrade/uninstall logic for specific versions of a managed package. We use a version.properties file in the root of the repo to specify the package requirements:
For the unbundled metadata, the build.xml has targets to deploy each subfolder of unpackaged/pre and unpackaged/post as individual metadata bundles before and after the deployment of the main package (see the deployCI target for the sequence).
I really like the idea of using a config file in the repo to specify the dependencies as that allows for dependency changes to track with a feature branch. I've been doing some thinking about a format for that file but haven't really settled on anything yet.