This modular loading architecture allows to provide just the modified/new driver (or extension) module instead of the full X server. The server can load this new module at run time and utilize its new features. The architecture provides an additional simplification. Since the loader code does not rely on the host OS in order to read and interpret object files, all the OSs on the same hardware architecture can share the same type of modules as well. Releasing a driver for a new card now is as easy as releasing a single ".o" file for the x86 architecture, and maybe the same for other hardware platforms that the device can be used on.
The installation of this new driver implies simply to copy it to a well known location (e.g., /usr/X11R6/lib/modules/drivers for graphics hardware drivers) and, if this is a new driver, updating the XF86Config file accordingly.
The logistical problem now boils down to issues of ABI versions in the loader code, the need for exported symbols from the main server binary or maybe the host system libc implementation, and of course the issue of authentication of modules. Let's quickly go through these one by one.
The application binary interface that defines the loader architecture in XFree86 has a versioning scheme that allows (through major.minor numbering) compatible and incompatible changes to different parts of the ABI. By defining the ABI version in the XF86ModuleVersionInfo of a module the server can determine if it is able to load and execute the module.
Since different classes of modules have different ABI classes it is possible to change the ABI for one subset of the server without having to modify unrelated modules. For example, video drivers and font renderers have different ABI classes.
The XFree86 ANSI C Emulation ABI defines a set of entry points and variables from the main server binary that can be referenced from the module. This includes many of the ANSI libc functions that are provided to the modules by means of special wrapper functions that allow portable access to host libc routines. This is necessary to make driver modules independent from special versions of libc and to make modules protable between different OSs for the same architecture.
Modules contain information on the manufacturer and the version of XFree86 against which they were built. This is additional information for the end user only, the relevant ABI versioning does not use this information. In order to be able to determine whether a module has been tampered with, authentication code that gives a cryptographic signature of the module (which can then be compared against a vendor-provided list of valid signatures) will be added.
At this point the code necessary to do this has not been fleshed out in detail.