I interpreted One of these databases links to a few tables in the other to mean they are split. Since I didn't read anything that indicated each user has their own FE (front end) copy I'd suspect it is shared. I'm surprised the developers did not compile the db into an mde.
The Estimating database record locking file never goes away and the database size grows exponentially
To me, these two factors indicate abnormal shutdown. The bloat could be from adding images, but I took the comment to mean it's rapid bloat without adding a bunch of new records with embedded files or images. In that case I'd suspect frequent making/over-writing tables with MT queries, too many temporary tables, frequent design changes, over-use of DAO or any of the other typical causes of bloat. IMHO, a new file with a compact date is of little value because that date is insignificant. Of more importance would be an update date (if local tables contain data linked via ODBC) or a design change date, in which case I'd store such dates in a table and present that date on a 'switchboard' or About form. Shortcuts? They are the preferred method for users to access a db AFAIC. Users should NOT be poking around in the folder where the BE or FE is kept. Nor should they be allowed to make copies of the db and dump them on their desktop, which I encountered more than once (until I took care of that). And anyone with a browser can figure out there's a shift bypass, so I'd make that more difficult as well.
EDIT: forgot to mention that I highly recommend you poke around and learn on a copy of the db - making sure you disconnect that front end from the back end (assuming they are in fact split) and reconnecting to your own BE. Otherwise, you would not be the first person to accidentally delete records from the BE, thinking what they were doing was acting on their own set of tables.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.