Your database server "can" serve multiple SharePoint environments, either by creating unique database names between environments, or by creating a separate SQL instance for each environment. Just because you can obviously doesn't mean you should... your requirements would dictate if that's a viable option.
As for the SharePoint end of things. To my knowledge, one SharePoint server cannot point to multiple SharePoint configuration databases. When you install SharePoint, there are registry keys that point to the database server/instance. In addition, you can't really install the binaries twice, so they'd share the same 14 hive (which pretty much kills any purpose of having a dev box).
In many cases, developers share a VM or run local VM's on their workstations to do development. Those packages get deployed to a staging environment for validation, then to production. There's really no shortcut to a robust testing and deployment process.
That said, why would you need separate environments to develop the two projects? If they're going to ultimately exist on the same production hardware concurrently, then they should coexist in the same manner in Staging. Development, as said earlier, can be done anywhere. Can't you just use the dev VM's from the first project to develop the second one?