We currently have an on-going design doc walking through our ideal implementation of Yeoman.next - a system of easily composable generators. Given the complexity of that task, we're likely going to need to break that proposal down into several sub-specs/tasks that we gradually introduce as generator system features. This gist is to mostly collect ideas that define how yo.next generators differ from what we have today.
The hope is that definitions will provide us some guidance when it comes to actually prototyping this system.
Passing custom configuration to Grunt task scaffolds
Another problem with this idea is that it assumes a generalizable set of configuration can be written by each Grunt task scaffold that is relevant to each project. That isn't the case. We would almost need a way to programatically pass configuration information from within a consuming (parent) generator to a generator it calls out. For example, path information, ideal settings (e.g for JSHint) and so on. Short of manually updating the Gruntfile/parsed version of it, unsure of how to cleanly handle this.