I'm not sure I understand your comment.
I understand that there are certain structures this information could be put into which would not, by themselves, provide any way to determine if they were sufficient to configure twistd. However, a well-designed structure would be initialized in such a way that (barring stupid introspection tricks) any TwistdConfiguration object is a complete and valid configuration for a twistd process. So I think I'm agreeing with you when I say that it should be so designed.
However, this particular ticket is an attempt to separate the definition of all the external hooks for overriding the configuration object from the configuration object itself. Thanks to platform requirements (you must bind ports before shedding privileges, for example) each twistd subsystem will need to have its own timing for calling application code to override it, so tickets like #638 should still exist separately; they can just be facilitated by having an existing, well-defined structure to manipulate.
Regardless, as you say, this is probably worth it just for the testing benefits.
