Just something to think about...
The module issue is not going to go away until the source code is split up into actual modules. I've seen a lot of suggestions on GitHub, but I don't think any of them take into account the future. The JavaScript landscape changes too rapidly to depend on one type of technology. Just look at the decline of Grunt and Bower.
Instead of creating modules for a specific loader (AMD, CommonJS, UMD, global), just create ES6 modules and let the user decide on the loader. This is the best way to design for future since it's going to be part of the language itself.
To show how this would work, I split the TweenLite file up different modules including: Animation, SimpleTimeline, TweenPlugin, Easings, Ticker, and EventDispatcher. The only changes I really made were to the easings, to allow exporting eases individually because I didn't include the current GSAP way of defining classes. I also added an object called "gs" that get's passed around to the different modules as a work around to all the variables that get reused in the original file. So things like the ticker and rootTimeline instance are on that object.
This was a quick proof of concept, and I really didn't do any testing so I might have missed something, but I am able to request GSAP modules in the browser using an ES6 module loader polyfill. This will also work with NodeJS.
So now I can request stuff like this... (although I didn't actually do the CSSPlugin)
// Get individual components
import { TweenLite, CSSPlugin, Power4 } from "greensock";
TweenLite.to(myElement, 1, { x: 400, ease: Power4.easeInOut });
Of course this is only for users that want to use modules. For users that like using source files the traditional way, you could create a "dist" folder with these files already built, similar to current file structure of the src folder.