This one's for a future release, since it requires a DB change and is fairly major change in mechanics....
Modify the population accounting so that more than one race can be present in the same population.
I just did my first genetic engineering gig - I created a low-grav race "Lunies" to colonize the moon (note that I expanded the range of human grav tolerance to +/-0.8 in SM mode to bring lunar gravity within reach). Once I started creating Lunies I ended up with a logistical nightmare in my colony management (ok, it wasn't a nightmare, but the colony management was a LOT more cluttered and error-prone):
1) I already had a lunar colony, but it was for humans. I had to make a new one and kill the old one.
2) Around the same time, I decided to run some colonists to Mars. Unfortunately, I clicked on the wrong Earth colony for pickup, and ended up creating a Lunie population on Mars.
3) I now have multiple Earths on the F2 and F12 screens that I need to be careful choosing between.
4) My Lunies can't work in earth industry once they've been converted; they're a completely separate colony. For example, I had to transfer troops to the Lunie earth to keep unrest down, rather than having the troops stationed in Human earth take care of it.
5) Growth rate for the Lunies on Earth is treated as if the planet is empty, it's much higher than for the humans.
Implementation suggestion: I think there needs to be another level in the world/population structure, call it sub-population, which differentiates on the basis of race. So if I have 990,000 Humans and 10,000 Lunies in a population on a planet, then it should show as 99% Human and 1% Lunie. The Lunie and Human populations would have separately tracked colonization costs (and infrastructure requirements), unrest levels, political status, and growth rates (but growth rate would be mostly determined by the overall population or even world head-count). Infrastructure, mines, etc. would be pooled at the population level.
Now that I think about it, this might just be a (BIG) coding change (as opposed to a DB change). You probably have a table with populationID, raceID, and headcount; if the populationID were non-unique you could simply use different rows with the same populationID as different sub-populations. (You'd have to create queries that summed over all the entries with the same populationID and empireID for things like number of CFs etcs.) This would also make it easy in situations where you conquer another race's colony - you'd simply change the populationID of the conquered population's entries to match the conquerer's populationID on that world.
I'm aware that even without a DB change, this would be a complex change that would probably be buggy for a while due to missed-out spots. It might be more robust to do it as a DB change, introducing a whole new table to manage the sub-populations and leaving the existing tables as aggregators of total population.
John