Thinking about this from a data-locking viewpoint, having separate non-identical FE files doesn't change anything at the Windows level or at the Access level. I see no issue UNLESS someone opens two different but cooperative FEs on the same machine at the same time, since both FEs would be opened by the same user ID. But they would be opened by different process IDs, so there would be potential for confusion. Potential, but not necessarily a guarantee of a problem. However, inter-process interactions could get interesting.
Thinking about this from a maintenance viewpoint, you now have multiple extra files to maintain when you have to change something. To me it just adds more work by adding more "moving parts" to be managed. It adds "clutter" and offers a far greater opportunity for something to "fall through the cracks." Careful - one might say nearly "obsessive compulsive disorder-level" - configuration management could control the clutter factor - but the easier way to address clutter is to never have any in the first place.
Thinking about this from a site- or project-security viewpoint, extra FE files mean more things to put through a security certification process, particularly if the LAN is set up with different security zones but users of this database must cross one or more zone boundaries. Modern firewalls have ways of blocking things selectively that are chilling in their specificity. It would all be MSACCESS.EXE, I suppose, but firewalls can call out strange connections based on the relative paranoia of the site's security manager. Here, the problem - if it occurs - stems from an overly zealous IT person detecting two different connections from two different process IDs running the same base program (Access) to access the same BE file. Just remember that all IT security managers must have taken college course Paranoia 101.