It just occurred to me how to avoid this whole problem, and make the statics mapping better. When the client loads, one of the first things it does is to map all the mul files. Now when I originally made the framework, the big issue with statics was the fact that whenever a static was added, the file size grew. This made the mapping invalid, and the client couldn't "see" the new section of the file because the client's view of it was made before that portion of the file existed. To overcome that problem, I would simply make the view 1.5 times the size of the file, and copy the file into memory. The major problem with this is that copying the file takes time, and if you play for a long amount of time, or if there are enough changes to the statics file while you're playing, there is a potential for the client to overrun its view anyway. Its unlikely, but there is a possibility.
I think there is a way to solve this problem, and the problem with the contiguous address space in the client. When the client first loads and tries to map all of its mul files, I will map three large views of memory, say 400 MB, 300 MB, and 200MB (900 MB in three views). Whenever there's an attempt to map any of the statics#.mul, staidx#.mul, or map#.mul, I'll simply redirect them to one of the large map views. This will force the client to use the same address space for all its maps. Whenever the client switches maps, I'll simply remap the corresponding view to the correct map file. The difference in the sizes will next be mapped so that the two new views will be the same size as the original large view. Because I won't be mapping the original maps initially, it will save some of the address space to use with the large views.
I will experiment with this next and see if there are any unanticipated problems.