A part of any project is a capacity analysis. Look at the records you are contemplating. How much data would you wish to store for a single project? If you are looking at 10 Mb per completed project, an Access back end can handle 100 such projects before it reaches 1 GB.
IN THEORY, the ideal storage is to take ALL of your project data that has identical structure and infrastructure and add a "project" field to the tables. Then you store EVERYTHING in the tables. Each record contains the ID of the project to which it belongs. "Translation" fields might not need project qualifiers because you said the structures were symmetrical to each other. When you want to focus on one project, you have to create ONCE what we call a single-table query that has a WHERE clause to select a specific project number. The query gets that number from your combo box OR from a global structure such as a TempVars collection. (There are other options, that's the simplest global case.) Then the form merely uses the selective query that works for ALL of the projects but only requires a simple selection of the project ID to isolate the desired records. IF you restrict the front-end structures to work only with the forms that have the project-selection combo, this is about as seamless as it gets. You DO have to secure the database. (See below.)
As far as long-term storage, if you ever have a completed project, THAT could be something you archive. And if so, you can use the same method of selectivity to copy the data to an archiving back-end or an external file. You can do an INSERT INTO of a subset of a table where the source records are qualified by that project ID and no other records are selected. Then, once the archiving is complete, you could delete the records from the main table.
You asked about the can of worms brought into play by having users of unequal duties. The "restricted user" problem is based on the concept of "roles" that a user plays. At database login time, you would have a table of authorized users AND that table would indicate the role - or roles - played by each person. If you do some searches in the forum for "Securing a Database" and "User Roles" you will find ample reading and much discussion on these concepts. You CAN create your own login or, if you have a formal domain with user logins, there is a way to ask Windows who you are and "trust" the Windows Domain login. And trust ME when I tell you that a Domain login, if properly interrogated, is far more secure than any form you would ever devise. If it gets to that point, ask. Our member Isladogs (a.k.a. Colin) has published many articles on that particular subject.
IF this idea of "separate files" is coming from your bosses, they need to see the discussions here and understand that the issue is RISK/REWARD. There is a HUGE risk in dynamically repointing file pointers because an Access "crash" during one of these "repoint" operations will potentially corrupt whatever it is currently sharing a connection. The difficulty in recovering a corrupted DB can be anywhere from trivial to impossible, so any strategy that minimizes points of operational risk would be a good strategy.
Adding another BE file adds another step to the maintenance of the data files because of something called "bloat." Databases grow disproportionately to the amount of data you add if you also do updates or other types of maintenance like "data scrubbing" to "clean up" what you've got. The compact & repair (C&R) issues ideally involve manual operations on each separate BE file and if you have a lot of updating then you WILL have bloat. It is inescapable. Again, if it gets to that, we can discuss it more for you. Just ask.
Can this multi-BE layout be done technically? Sure, if you are determined enough and careful enough. But... what are the risk factors? The labor costs to minimize risks is where this problem will start to bite you... hard. AND, because this is essentially a symmetric multi-file solution with limited sources of verification (i.e. knowing absolutely that you are pointing where you should be pointing), you could do a LOT of damage if your point at the wrong place and start editing data.
By implication, the data files will be symmetrical, nearly indistiguishable, with respect to each other because if not, you have a LOT of queries, forms, reports, and modules to update for each project. And each time you add a new project, it gets worse because of the overhead involved. Keeping it all together in a single file with a single set of tables qualified by project ID means to add a new project you add ONE ENTRY to the project table and you are on your way. You will have to document anything you do including a full description of the projects for which files have been created. Adding a new project means you add a new project ID and file spec to the combo box AND you have to replicate the tables - and of course, you have to test that you got it right for the new table AND that you didn't break any of the old tables. Which over time becomes a problem in factorial math for the workload - particularly if these project EVER share data. No, I'm not kidding about the factorials. In fact, if it ever occurs that projects DO have to share data, they had better not touch more than 14 other projects because of the limits involved in having multiple BE files open at the same time.
Also, switching from one file to another in the same session will RAPIDLY consume system resources (in the form of file handles and dynamic scratchpad memory for the Windows Operating System.) You will be INVITING the Windows System Error "Out of resources" - which is one that you cannot apply a meaningful Access error trap to prevent. Windows won't even BOTHER to let you back your way out of that gracefully. It will be BANG ZOOM CRASH right then and there.