I have been thinking about this myself and I came to several conclusions:
- Create one version of the framework that can be used in both global and AMD setting
- Don't obsess over having to ask your clients to include dependencies manually, it is a one-per-project activity and should be done anyway, whether you provide an AMD-packaged or global-scoped framework (3rd party dependecies placement will have to be adjusted anyway, is what I am saying)
- I use Grunt for project building/packaging/testing/linting/whatever, so for all other packaging alternatives I have different tasks.
So, in short, build for "old-school/AMD" first, package for "new-age" later.
P.S.
I am also a firm believer that your packaging and delivering process/need shouldn't (whenever possible) dictate your architectural and development decisions.
I try to build the most customizable, modular and usable code I can, while using the packaging paradigm of my choice, then I consider alternative packaging. If I succeeded in the first part, second one is normally either straight-forward or requires very little codebase changes (because of the modularity and proper principles application in the first step).