Hi Anne,
I've taken a look at the site you sent me - I've deleted your last message since it contained login information, and the password has been changed.
However, it looks to me that you are taking a good approach. I see you have changed the label in the Browse menu already - don't forget you can change the user interface labels (Via Admin > Settings > User interface labels) as well; and there is also the link in the Add menu to change. There may also be a better term than "subdatabases" which will be clearer to your end users, but that is entirely up to you!
Here's the public catalogue of Simon Fraser University as an example. They use 1 AtoM installation for both the Archives & Records Management Department and the Special Collections & Rare Books department. In their catalogue, they call them repositories, though they might equally have used "Departments".
Another bit of functionality that might be of interest to you in the 2.4 release - the "Insitutional scoping" setting. It essentially adds a dedicated browse menu and search box per institution. See:
Note that you can also now relate your authority records to a repository as its maintainer. This might be a good way to clarify which is maintained by whom, while still allowing both repositories to link to them as needed. See:
On the edit side, things are a bit trickier if you want to restrict permissions for users on a per-repository based. You can try limiting the permissions of your users by repository (I would suggest creating two groups, 1 per repository, and starting with the Editor group as a template and then adding further restrictions by repository), but be aware that there are performance implications when you add too many permissions. You may want to review these posts I've previously made on the subject:
When AtoM was originally designed as a multi-repository application, the focus was on multi-repository access - the use case at the time was many different users with their own archival management systems (AtoM or other) contributing descriptions to a portal site or union catalogue for public discovery - NOT a fully multi-repository system in both front and back ends. We'd love to see AtoM eventually support this level of functionality but it will likely require significant development.
I hope this helps! Let us know how it goes :)
Cheers,