I agree with the side effects argument, these could me methods. But I disagree with using asynchronous methods here.

Just for a reminder, we tried re-factoring the plugin resolver to be asynchronous and at the end we lost performances even though we could parallelize the disk search. The asynchronous interface add a performance overhead and when there's performance gain, it isn't saving much time in a context where our application serve a single user at any time.

So, I believe the logic overhead added by providing asynchronous API for non-critical part of the Yeoman core seems futile.

-------

Now about breaking changes. We've been very careful on past release to keep backward compatibility until we prepare 1.0.

This is very important. Yeoman community created lots of generator and we're introducing core changes with composability. It is crucial we keep backward compatibility while we introduce these changes so it is easy for author to upgrade their generator.

Easy upgrades means it is easier to bring everyone up to a strong interoperability baseline. If we decide to start breaking the API in the middle of these crucial updates, it mean we'll lose some generator and author who're not keeping up to tab with our changes. That's why we must keep backward compatibility for now, and only change the design errors we made before releasing the 1.0 Yeoman core. That way we can keep our generator/module ecosystem strong through our current goal.