additional points:
- Much of the code has unit tests (simpletest, php-mock-functions w/o runkit)
- Code was designed to be extended for custom purposes.
- I work with D5 though D7 sites, although not all the scripts work on all version.
- Developed on linux, some scripts used on mac, most certainly doesn't work on windows as is.

i started with drush but i also started with the installer so i
quickly realized i needed a running system to run drush. Once the
installer was done, I could have turned back to drush for the other
features, but i didn't.

The actual CLI part is abstracted out into an isolated piece of the
code. That is to say, the core logic exists in separate files unaware
it's running in CLI so drush support should be fairly easy.

pwolanin pointed me to the Acquia daily test results back in
Szeged, and I downloaded the cli-utils you'd put together back then,
but promptly forgot about them. I was reminded while listening to the
latest lullacast today, though.

Since Szeged, I've fallen in love with git-sh, and
had the thought that it'd be cool to turn drush into that kind of an
interactive shell. Moshe agreed enthusiastically when I ran it by him,
at least at the conceptual level. I think that such a project would
necessarily be rooted in the 'include-a-Makefile' paradigm that you've
got going on here, but might also be able seamlessly manage the
transition between working with an empty directory to grabbing a fresh
copy of drupal, installing it, etc.

However it ends up working, I think the direction you've gone with
these tools is really nifty - that CLI arg parsing, for example, just
makes me all too happy. So if I ever do find time to work on such a
thing, I'd love to figure out how some (most? all?) of what you've
done with these utils could fit in.