Obviously if your master.lsp does something else beyond loading files, it can't be totally removed, but the whole idea of .vlx is that the system loads all the files as one operation.
So any explicit load commands in the program referring to those files are superfluous, and won't work unless you also deliver the individual files, which is totally against the whole idea of collecting the stuff into a .vlx in the first place.
It sounds like your application is done interleaving loading files, executing programs, modifying the drawing etc.
It is possible to do this way, but the result is easily rather nasty to maintain and debug, and it is a bad fit to using a .vlx file. What happens with all those side-effects when you re-load the file during debugging?
When working with .vlx you do not have the concept of a subordinate file. All the files get loaded at once as one operation, you can't do anything between those. Better stop thinking in terms of files at all, you are living in one flat namespace where all the function definitions and global variables are visible at once.
A cleaner design would pack the global function definitions inside some initialization function, so you can decide what happens if you re-load the file during debugging: do you want to reset to original value, or do you want to keep the value the variable has at that moment? So the .lsp files would only contain (defun ...) calls and comments.
That way loading the file has no side effects requiring Undo markers around it.
The Undo marks (I prefer using vla-startundomark and vla-endundomark to calling command-s) would be inside the defuns, only where those are actually needed when the function modifies the drawing.
