I'm a bit late to this discussion, I'm afraid, and I must admit I haven't had the time to read all nine pages of posts, but since I lead a small team that has been developing an Ubuntu customization that runs on netbooks from an SD card (Balsa), I thought I should share some of our experiences.
First, it's very, VERY important that users don't accidentally overwrite the wrong device. IMHO a command-line tool is threfore simply too dangerous. We have been using the Ubuntu Win32DiskImager with a fair amount of success. It had a few bugs in it but I and others have been fixing these and a new release was made about two weeks ago. It's Windows-only, but there is an equivalent utility for Linux that has a similar UI (usb-imagewriter). It's written in Python, uses GTK for the UI and dd for the actual writing, so it should be portable to Mac as well (running under X11).
We produce ready-made images for 4 & 8 GB cards, and compress these with 7zip. They have the same files on them, and compress down to the same size. We encourage Linux users to download them with zsync, which allows restarting and provides checksumming, which saves a lot of problems. Unfortunately, I haven't been able to build a Windows version of zsync yet (although I'm sure it's possible) so we tell Windows users just to use their browser. However, we strongly encourage them to run a checksum on the downloaded compressed file, because we don't want to waste time on support requests that turn out to be the result of a corrupted download.
So the set-up sequence for a Windows user is:
Download the image file
Download md5sum, 7zip and win32diskimager
Use md5sum to check the file
Use 7zip to unzip the file
Use the imager to write the file to the card
The sequence for a Linux user is similar, except that the three utilities at step 2 are packages to be installed, and the image writer has a different name (usb-imagewriter).
Like R?, Linux is in a single, large ext3 partition, and this requires us to have separate images for each card size. However, we're planning to change this, in one of two possible ways. The simplest solution is to put /home in a separate partition that gets almost all of the free space. It's then possible to resize it from the running system by unmounting /home temporarily, or even doing it automatically on startup if there is unused space on the card. However, with a split system like this there is always the potential for running out of space on the root partition. So another possibility is to have a single partition that gets expanded on startup while Linux is still running out of the initrd (initial ram disk) before it has mounted the root partition. This requires putting parted and resize2fs into the initrd, which would cause considerable bloat, so we would create a single-use initrd that does this and this alone, and switches in the regular initrd just before it finishes, and then reboots.
I think we should avoid reinventing the wheel here. Good card imaging programs already exist, so there shouldn't be a need to write new ones.
It would also be good to collaborate as much as possible. I'm very interested in R?, and since there is considerable overlap with my day job working on our Balsa project I would be glad to contribute something for resize-to-fit on startup. I've already produced a customized, one-off initrd for other purposes in Balsa, so I have a head-start on something for resizing. Also, I use Debian as my main development platform so I should be comfortable with tweaking the R? Debian system.