We (http://redandivory.com) have gone though different approaches in the past few years to build multiple meteor apps from the same source base. Most of the past approaches used concepts like git submodules or private smart (meteorite) packages to share private app-specific packages over different meteor projects.
We are currently looking at a new approach, where we don’t need to separate common library-code to a different repository and don’t need to setup a meteor-project for a new build.
First, let me elaborate on the use cases for having multiple meteor builds (and i don’t mean builds for different platforms, but builds for different uses in your platform stack).
Use Case 1: I want different user groups to use different apps.
Say you have an app with completely different enduser experience depending on your role. It is common practice to have the user loggedin, and setup different routes based on the user’s role, and load different templates to serve that type of user’s needs. But all types of users, load the same app, and the app decides which portions of the build to use and not to use. This results in builds that can be way too large for a user with a role that can actually do very few things with your app. A common example: a unauthenticated user just needs to be shown the landing page, must be able to login and to register a new account.
Furthermore, this approach leads to security vulnerabilities. Because all of the logic is deployed and catered to all users, whatever their role, you must be damn sure your access rights are checked all the way through in every aspect of your app. It would make more sense, just not to load the code for users who don’t need it or shouldn’t use it.
To support these use cases, one should deploy different apps to gewgl.io, app.gewgl.io, admin.gewgl.io, … and make sure the right user uses the right app.
Use Case 2: I want my backend to be made up of microservices
Say you have a very computation heavy process somewhere in your backend and you know this is going to have scaling issues as soon as your userbase grows. You want to be able to separate this process from the rest of your app, deploy it as a independent service and scale it seperately as your userbase grows.
Of course it is possible to set this process up as a different service, and make your meteor app communicate with it as with any other 3rd party service (or even better with DDP, since their are both meteor). But if you want to do this for 15 different components within your backend, this process of building different services can get very tedious.
It would make more sense to build all the services in your single app during development, but build separate apps for all the different microservices as soon as you build for production.
To support both of these use cases within the core of Meteor, you should be able to control the contents of .meteor/packages when building your app for a certain context. The problem now is your packages file is fixed for the current state of your app and you can’t change this packages file during build, because another meteor app might be running with it and reloads as soon as the file contents is changed.
So I’m basically looking for the support of multiple .meteor/packages files to be able to build different apps with other package dependencies from the same meteor project.
Does anyone know of an approach that is currently supported with meteor core, that results in the same benefits?
Does anyone know if MDG has support for these use cases on their roadmap?
Thanks for reading this far 
Kr,
Pieter Soudan