Thanks for responding. I think you're one of the best voices on this given your work on LinuxIce (which I am still looking forward to testing, BTW). Your insight is very helpful. But if you don't mind, I have a few followups to your post.
1. Screen is too small: this assumes that any front end for the Droid would behave the way everything else on the droid does. Why couldn't you have four user-configured buttons that say, simply, M (for music), N (for nagivation), O (for OBD2) and P (for phone). I know this is a bad example but my point is that even with the small form factor, you could design something that requires minimal input from the user. While it might give back less info than a CarPC frontend (for example, the name of the song scrolls OVER large buttons for play or FF instead of taking screen real estate ABOVE those buttons), it would still be visible and functional. As an example, my wife's XM radio has a four-line screen with no graphics, little detail and all it says is what song, what station and the number of that station. Yes, the buttons allow you to change station and that has to end up somewhere on the screen if you had that on a Droid, but my point is that we accept even less functionality, size and image quality from devices we are already using in a car environment.
My last point on this is that someone will figure out that people want a video out on their Android phones (a few other makers already do this). And Lilliput just demoed a touchscreen that uses only one USB port for power and input signal. I don't know my way around the power draw for something like this but it seems that it won't be long before we're sending the video signal to something large enough to make this first point moot.
2. The UI is almost useless in the car: again, I believe this starts from the assumption that all options on the Droid would be used as/is without some mods or cleverly designed UI that makes huge buttons (no more than a few at a time and maybe some gesture options which take you forward or back a screen). I understand that no one has done this yet but are you saying that no one can? I just don't see a smart developer designing a frontend and then insisting on keeping the font the same size or making the buttons impossible to read at a glance.
3. You have to port some carpc frontend to run on it: why would you have to port something? Why can't it be designed from the ground up, using the inherent advantages/limitations of Android? Again, I know this can easily be dismissed by saying "Well, go out and design it then, if you think it's so easy." I know it's not easy. But if the device that gives me access to all my in-car entertainment/information is the same device that I can bring up to the office or take into a restaurant with me, I would think that kind of elegance and simplicity is something people would pay for. The idea that I don't need an extra GPS dongle, network dongle or bluetooth dongle in order to do most things and I get everything in a small package that just works, seems like a pretty decent argument for using this as a platform. There will always be people who want the extra power and scalability of a full-on CarPC. But if you could get 90% of the functionality out of a device you already have in your pocket, wouldn't that be a good thing?
4. Can't correct #1 (the small screen size): no, but you can design for it.
Look, the Android OS will not be the panacea for the CarPC movement. But if you can get 90% of the functionality most of us design a CarPc for, I think it could really go mainstream and allow the user the level of customization some of the dealer-supplied options (like Ford's Sync) don't allow for. It just seems like we're on the cusp of something really interesting and potentially really big.