Exhibit 1: A comparison of the two phones. While not entirely 1:1, essential elements--like the sharing of the ARM Cortex A8 processor and 16M colors--are there. Though the screen on the N900 is resistive, so is the screen on the HTC Tattoo, and they've already committed to releasing Android 2.0. Which leads me to...

Exhibit 2: Droid GSM ROM dump. If nothing can be useful here for the N900, you can bet the nice folks at XDA will do something similar for the Tattoo.

Exhibit 3: "I have just committed the remaining puzzle piece of N900 bootmenu". There's the selector.

Although admittedly this is all theoretical, what's missing to get these pieces together (aside from time)?

Well, beyond the glaring legal problems it is technically possible.

You would need to patch a N900 kernel to have Android extensions.. and you might run into HTC specific services that will block running it on a N900.

N900 has 65536 colours, although I don't expect that matters too much.

It is apparently a requirement of Android 2.0 that the screen run 16M. The X10 runs 1.6, but not 16M. With 2.0 that limitation goes away (according to Sony).

i run liqbase in 16.7million colours i think
at least the code from my side is 24bit and I dont usually notice banding.
(yuv mode FTW!)

Well the frame buffer only has enough bits for 65536 colours, as I understand it.

I'm sorry, what are the glaring legal problems? I thought the android OS itself was opensource?

I think it was distributing the Google applications was problematic (at least that's what the issue was with CyanogenMod)

And I'm pretty sure the Android phones are 16bit too.

If it's possible to compile a "clean" N900 kernel with working features you'd want in Android, the Android 2.0 userspace is actually very straightforward to build. I did it on a whim last night for N810, and besides nonworking N810 features / extra loaders / all the crap that comes with closed/proprietary kernel extensions (loading wifi firmware, DSP, and so on) it's working quite okay. Depending on the state of the N900 kernel merging the Android extensions could be a quick merge and compile or a little ordeal, but shouldn't be too complex as they don't interact too much with other parts of the kernel (they mostly extend the kernel to monitor memory, kill tasks, and provide logging services, rather than hitting any hardware or mangling any drivers or kernel structs).

Making Android work with a new baseband/radio is something a little more tricky, again depending on the N900 kernel (which I know very little about). The people who ported Android to the HTC Vogue did it, though (they even reverse-engineered the baseband driver, although they didn't have to do the hard parts like bringup since Windows Mobile did it for them).

Overall there is no reason this is not possible given a working, clean, user-buildable N900 kernel which I have yet to see.

Android 2.0 will run fine regardless of the LCD's actual color depth - what it needs is a 16-bit RGB565 mappable framebuffer, which almost all framebuffer drivers provide (including the N8xx's and presumably the N900's).

All of this shady leaked stuff and HTC code is unnecessary - the Android 2.0 source is freely available from Google themselves and compiles up just fine. The only time shady (legally and functionally) dumps are necessary is if you want the By Google apps, which isn't really relevant to "will Android run on the N900" anyway.