Yeah, I'd go with option 1.
However, are these different databases currently on different development and release cycles? If so, putting them all into a single database might prove to be a bit of a horror show. I've seen it be a major problem in the past. Different teams make different changes on varying schedules. You have two options. You'll have to branch the releases (which means different databases in development) and then merge them through QA or some other pre-production stage, and then deal with all the discrepancies as the varying changes to the database have to get resolved. The other option is to get the development teams to coordinate their releases and communicate well with each other. Good luck.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning