I don't think we really have any technical reason to restrict EXPORT_FUNCTIONS to the standard phase functions defined by EAPI. The same aliasing behavior is sometimes useful for custom functions. I can think of two examples: 1. 'Pseudo-phases' used e.g. by distutils-r1.eclass. Right now the eclass explicitly aliases 'python_test() { distutils-r1_python_test; }'. While it's not a big deal, I suppose it would be cleaner to use EXPORT_FUNCTIONS consistently for it. 2. Custom phase functions for internal use. In particular, I'm working on moving smart-live-rebuild logic to a phase-like function.
