Before people start asking I should explain why I started this: https://bugs.gentoo.org/show_bug.cgi?id=458638
I think having such an eclass has several advantages over autootools-multilib.eclass (which depends on autotools-utils.eclass) as it is now: a) Less eclass dependencies. One could argue: the more eclasses my ebuild uses the more prone to error and exposed to changes it is. b) easier conversion in some cases: often times a simple rename src_compile -> multilib_src_compile will do c) it allows more custom definition of phase functions d) the previous point will also allow to convert go-mono.eclass packages without introducing yet another eclass for that e) autotools-utils.eclass does a bit more than just calling default phase functions; the developer has little choice on this matter unless he wants to rewrite his ebuild based on multilib-build.eclass which will create a lot of code duplication in ebuilds, hence this proposition I don't have a problem with the present eclasses, but I find this a logical enhancement.