Migrate module workflow refactoring

I'm in the middle of implementing Update migrated content in-place, while thinking ahead to Workflow integration. The checkboxes on the current dashboard basically are defining a default workflow, for use by cron processing or the drush migrate all command, and adding the update option is making this just a little too complicated. So, I'm going to take a little poll here, followed by a description of what I'm thinking of in terms of a V1 dashboard and workflow approach, while anticipating a full implementation of defined workflows in a future version.

1. Do you use migrate module's capability of running migrations via Drupal's cron.php? If so, how difficult would it be for you to turn to using Drush for running migrations?
2. Is the capability of running multiple migrate operations (e.g., turning on a clear here and a couple of imports there) interactively from the Dashboard important to you? Or do you generally just use interactive migration for single operations like running a 100-item node import for testing?
3. Do you use the processing API functions (migrate_content_process_import() etc.)? If so, would refactoring these functions (e.g., changing arguments) be difficult for you?

So, here's what I'm thinking... First off, let me make clear that I consider the primary purpose of the migrate module as providing services to developers handling complex migrations from other CMS data to Drupal. If less-technical users doing fairly simple migrations manage to make use of it out-of-the-box, that's great, but the design center assumes a fair level of technical sophistication - and shell-level access to the server (i.e., the ability to run drush commands, and to schedule them via cron). The API should be optimized to support drush operation, while permitting other UIs to be built as well (i.e., defaults should reflect the drush context).

Now, most of what I'm looking for with workflow integration can be done today simply with sequences of drush commands. E.g.

So, I would deprioritize trying to define workflows in the module for now, and revisit it after (finally) getting Migrate V1.0 out. My tentative plan (pending your feedback) is:

1. Implement Update migrated content in-place via drush only for now (I have a short-term need to release this capability, and don't want to have refactoring the Dashboard page hold up committing this). This is basically done for nodes, needs more testing and extension to other supported destination types before I commit (within a few days).
2. Refactor the management of content set flags (clearing, importing, scanning, semaphore), and the migrate_content_process_*() APIs. The clearing/importing flags have been somewhat overloaded, used both for enabling processes and showing status, and scanning is simply ill-conceived and needs to go away.
3. Along with #2, refactor the Dashboard page - eliminate the system of checking off operations, in favor of simple buttons to run single interactive processes. Actually, maybe the content set listing and dashboard pages could be merged...
4. Potentially, eliminate the cron operation. If it's to be kept, then there will need to be a means to select which operations are to be run via cron (instead of the current global cron enable/disable).
5. Eliminate drush migrate all - to run a particular sequence of actions, you will need to use a sequence of the individual drush clear and import commands.
6. Support clearing all content sets, or importing all content sets, simply by omitting an explicit content set on the drush migrate clear/import commands (alternate approach to http://drupal.org/node/649368).

Thoughts?