Currently, to hook into the u-i build process, you have to use the --thru, --until, and --resume options to temporarily stop the state machine, do some out-of-band tweaking, and then resume the state machine to produce the image. While darn handy, and a very useful debugging/testing feature, these options are very problematic for production.
State machine method names and indexes are *not* considered part of the public API so I make no guarantees they won't change, even though I try not to change them arbitrarily.
What we need instead is a collection of official build-process hooks and a mechanism for users to invoke them. Such hooks *would* be part of the public API, with the expected backward compatibility and stability guarantees.
We need to do two things: first, we need to identify the possible hook points where users of u-i might want to modify the image content, etc. They probably will not be as numerous as the number of state machine steps. Second, we need to identify a machinery for actually specifying, locating, and running the hooks.
raised this question privately, but also documenting on the bug: I am not convinced that we want a generic hook mechanism, vs. a limited mechanism to declare files to be copied into the root filesystem.