I think this is an idea worth exploring, but we'll have to re-survey the current config step classes carefully before proceeding.
There are certain methods (_init and runstep) which are part of the public interface each class must implement. _init(), in turn, must provide a 'description' attribute and (IIRC) initialize the 'result' attribute. Then there are methods and subs that are shared among 2-5 config step classes each. These are found in Parrot::Configure::Step::Methods -- and they're there not because of a big architectural decision but simply because, having been writing tests for the steps over the last 10 months, I noticed repeated code.
