I'll start with your last question first. Separate vs. combined is a trade off, there are advantages and disadvantages to either approach.
Merging the files takes a lot of work and you'll need to have a good understanding of how filemaker databases work before you take that on. It would also help to have Filemaker Advanced so you can use it's design reports to better manage the process. There's also a 3rd party tool: FMMigrator that offers better tools for merging. I haven't used that product, but it's the first one I'd look at if I had to merge any more existing files.
An all in one file is less confusing to the new filemaker developer as it's easier to control navigation from layout to layout and easier to set up your scripts to do what you want with each layout.
Keeping the files separate avoids the work needed to merge the files and you can link them fairly easily. However, if you want to use existing layouts or scripts in the different files, you may find you have to add some write scripts in one file that pass information to a second script in the other file and vice versa.
I recommend you work with a combination of the two approaches. Study the relationship graphs carefull for each file and figure out how to link the tables of each file. You can add a table occurrence (that's one of the boxes that identify a table in the relationship graph) that comes from an external table. You can also take an existing table occurence and use it to refer to a different data source table such as a table in another file. If the table in the other file is identical, all is simple. If not, you'll need to understand the differences and make changes to tables, layouts, scripts as needed.
This is not as simple a process as you might like, but that's why these are called "starter solutions" they're intended to give you a good starting point for how a filemaker solution might work for you. You might find it is easier to build your own solution using the different starter solutions for a model.