We have been working on this (while waiting for AutoPilot ;) ) and we have set up a solution which looks like yours but ... we are doing it manually.
We are actually using the update_N functions with a combinaison of content_copy, views_default_view [0], macros and some Drupal API functions (such as drupal_install_module) and so forth and so on.
With that we are able to face heavy upgrade but there are still some problems that you could also have with your framework. Of course your solution has the (immense) advantage to be automatique. Our solution is a pain in the ass (to say it frankly).

• Reference to numeric ids : let say that you need to creat a nodequeue that will be referenced by a view. In an ideal world we have a deploy nodequeue and a deploy views. The fact is that the view is refering to the nodequeue by its numerical id, given by the db_next_id() function. If everything goes smooth you create your nodequeue (nqid = 1 for ex) on the dev, then you create your view which refers to nqid = 1. Deployement : creation of nodequeue nqid = 1, creation of the view, nqid = 1. So far so good. But let say that the developer create a nodequeue, then delete it, then create a new one : nqid = 2. He create the view (refers to nqid = 2) and Deployement :
  creation of the nodequeue (nqid = 1 because it is the first in this db) then import of the view which is still refering to nqid = 2 !

  I can see 2 solutions to face this problem :

  • Take the id from dev to prod. It solves the problem of the reference but it brings a new one : id collision. It could be solve by the even/odd id trick (BTW the original post you were looking for is here http://drupal.org/node/181128, and they are using this solution at http://www.france24.fr).
  • Bring the concept of dependency in the deployement process. Say that you have a view that depends of a nodequeue (it could be anything else like a node or a user btw). If in your deploy plan you can say that step B (deploy view) depends on step A (creation of the nodequeue) you can then abstract the nqid in the view to be the nqid of the nodequeue previously created. We are doing it by hand (= in code, create a nodequeue, retrieve its nqid with some sql, put it in a variable, change the exported views to refer to this variable instead of the original nqid).
    This step could be automated but it would be quite complexe, given the number of different dependencies that are possible.
  • Actually there is a third solution ; deploy in 2 times. First create all the objects that need to be referenced and deploy (sometime they could even be created directly the prod server). Syncronise your devel db from your prod one. Create the view/menu etc... that refer to the objects created in the first step. Deploy the second step.
• Managing the changement in the db : this mean that while you are developing your "new features" you can' t synchronise your dev db from your production one. Or if you do it, it will :
  1. erase your deployement plan and its component (but ok, the table could be saved and reimport in the fresh import)
  2. erase all the modification that have been done in the db (creating of new content type, new views, etc)

  If, instead of keeping the changes in the db they are "frozen" in code, it is very easy to sync the dev from the prod : dump your prod, import it in the dev db, apply your update_N function et voila. Of course, you have to *write* your update function which is boring and time consuming.

• AJAX/AHAH: asyncronous method are making there way into drupal admin in D6 (which is a nice thing). Asyncronous calls don't rely on the drupal_system_settings or on drupal_execute (correct me if I am wrong, I am saying this without looking at the code). A deployement implementer should be provided for every page that have ahah functionnality (blocks and menu for exemple)

Given that (sorry for the length of the post), your solution looks very cool and is probably the most promising one that I know.

We would be very happy to share with you the work we have done and contribute to your module.
Feel free to join me by email if you want to.

[0] which can be overriden by the administrators and then re-import by the developers