Without a doubt there are many viable options, yet all parties must be willing to accept it. I unfortunately play the role of code monkey, with one of our other offices heavily fortified against change...They still use hand written invoices.
As such, I'm forced to have all AutoCAD related files: routines, hatch patterns, and so forth; for my applications within the same folder. It's hard to explain, and I'm not fully doing it justice.
The cause of all this is, logic forbid, one draftsmen updated their LISP files while others neglected it, providing varying outcomes in routines.
what about the possibility of standardizing your file locations. for main files that are loaded on a network, have it run via a mapped drive. use the "vl-file-directory-p" function to determine if the standard folder exists on the network. I use this method for our multi office environment to load lisp routines on a custom basis, in a combination with the user's loginname.
Our network folders are mapped as such, but my office applications interact with a MySQL database storing block details and managing drawing revisions and time management/logging, each action requiring the employee ID for interaction. And all routines are loaded regardless of usage (these routines were developed circa 1997) and unfortunately don't use dynamic loading, some commands even override AutoCAD defaults such as `bedit`.
As for
main files...These don't exists. Everyone has everything. If a toolset was provided to remedy a problem, such as the massive viewport scales list a while ago, it was push onto everyone else within the company involved with AutoCAD.
My main goal was to uniquely identify each user using the shared resource, while utilising a common configuration file, allowing a single resource to define the company standards and also include individual user settings (one of our offices have drafters with the same login name). By creating a hash of each computer name, username and first (non-removale) drive serial, I've managed to get this to work. Accommodating all branches of our company.
It also prevented me from going through all my code looking for areas to refactor (I think I changed 6 lines total, created one variable and altered 5 string references).
I will admit that it's an odd solution, yet it's clean and scalable enough for our branch sizes while complying with multiple office standards.