Backporting Forms API to 4.6. Experimental migration feature

I've been working on an idea.

Mission

To move my development modules into 4.7, without losing compatability with my establised 4.6 client installations.
We will not be commiting to 4.7 for a while (if ever) but the features I'm developing deserve to be forward-looking.

Problem

To even get the old modules to work in 4.7 requires a significant rewrite.
Doing so would branch the code, then make added features (developed under 4.7) harder to apply in parallal to the target 4.6 implimentations

Experimental solution - a hybrid 4.6/4.7

I'm converting my modules to 4.7 but adding the bits of the forms API that I need as a conditional library that will bring the 4.6 site up-to-date enough to be able to handle it.

From the library :
forms_api_backport.module

---

The idea is that we can convert modules to using the 4.7 forms API
and such, WITHOUT abandoning 4.6 support. This is a backport, not
a legacy library. Modules SHOULD convert to the 4.7 model, but these
modules can continue to work on 4.6 without truly branching the code.

Functions here ripped bodily out of 4.7 wherever I could find them.
(basically all of 4.7/form.inc). Apologies for munging what used to
be some elegant code.
I commented out the bits I didn't need or understand, and the duplicate
function names. There's probably some concepts I've missed.

Functionality is of course incomplete, and may not work as advertised.
Error handling and the advanced features of forms (like secure validation)
won't work, but they hopefully won't break either,

Only tested and tweaked in specific examples, the code has not been
fixed to solve the general case. I don't even understand half of the
coolness of the new API (although I love the look of hook_elements())

Usage.
It requires a tiny modification of 4.7-compatable modules -
specifically when they come to return the $form they may have constructed,
like they do in a hook_settings page.
After constructing a 4.7 - style $form array, and before they return that
array, they should check whether the system will be expecting an array or
an HTML string. If it's 4.6, you should return the formatted (flattened)
$form instead. This is done as follows (using the htmltidy module as an example)

   function htmltidy_settings() {
    //
    // ...lots of stuff chopped...
    //
    // Build the form 4.7 style
    //
     $form = array();
     $form['htmltidy_process_input'] => array(
        '#type'          => 'checkbox',
        '#title'         => t("Validate input text"),
        '#default_value' => variable_get("htmltidy_process_input", TRUE),
      ),
    //
    // Return form array, OR render form 4.6 style 
    //
     if(module_exist('forms_api_backport')){
       // in 4.7 emulation mode
       return drupal_get_form('htmltidy_settings_form', $form);
     }
     return $form;
   }
 

Using this method in other circumstances is possible, but may need
extra work. Basically, half the modules out there only need to use
the forms API for their settings and admin pages, and the interface
to them is reasonably consistant.
Complex modules that modify the node edit pages need to work a bit
harder, but many can probably go hybrid pretty easily.

This tool is targeted at 4.6 modules that don't make any use of the
4.7 advances yet anyway, but want to at least go 'hybrid'.

---

Thoughts

I know there are some drawbacks, and I know it's not elegant.
It's an interim solution, and does introduce a small amount of version-sniffing bloat, BUT it doubles the audience for my modules and (some UI inconsistancies aside) will mean that the two versions are running the same code.
It encourages the great leap forward into 4.7 conversion without the commitment of abandoning stable, working sites.
The 4.6 compatability hack can be cleanly abandoned any time in the future, but shouldn't really impede progress any more than current version branching does.
The code I copied this afternoon will not apply across the board, it just sits in places where modules used to return a $form string and now return a $form array. I know there are conceptually bigger pictures to the new API, but older modules don't care about them!

Comments?
Is this worth a module project, or should I just leave it as a library for my own packages?

.dan.