If you're not going to support using site-load except in the most trivial of ways, then you should say that in the documentation.  I don't think it's unreasonable for a user to expect to be able to load a core emacs library in a file provided for loading additional libraries without it blowing up in their face.  Being cryptic in your documentation is a poor substitute for just explicitly stating that it won't work for most of the core libraries (unless they are "arranged to be" pre-compiled), and no attempt to facilitate such customization will be supported.  Why even include the option in the official distribution?  OS vendors are perfectly capable of maintaining patches that modify the build process to customize it to their system.  

 I'm asking because I'm trying to use this supposed feature on a close to stock source distribution.  I've only been changing the lisp libraries because I did not want to debug C code just to preload some stock libraries.  To the extent a small set of bugs in the C run-time and my ignorance of the process were responsible, I'll gladly dump the changes to the lisp code and make the few small changes to the C and the construction of my site-load file.  I'd prefer to make those changes in a way that would be most likely to be accepted to the core (assuming I can get cleared by my employer), so that I don't have to maintain these bug fixes locally indefinitely.  And it doesn't hurt that other users might benefit from a usable site configuration in the build process.

But if you're not going to be willing to take up such bug fixes on some general principle (that I don't understand in a free software project), that would be useful to know.

And yes, I consider segfaults and runaway allocation during the execution of lisp code (not due to the semantics of the lisp code) to be bugs even if it is during the build process.  Especially when that behaviour is from loading stock libraries from the distribution itself, and site-init and site-load are documented features.

Your inference that a user who doesn't utilize these documented features will not be impacted by bugs in these features is presumably correct.

Personally, I am going to proceed with the last option (the fifth) of having the interpreter do the replacement of a documentation string by 0 at the time it's attempted to be stored as documentation during a bootstrap dump, rather than at read time.  That seems a lot cleaner and robust to me than either the current approach or my other ideas.  It would have the additional benefit of removing the dependency of etc/DOC on any source lisp files.  If that functions well, and I'm cleared to assign the rights, I hope it would be considered for inclusion.

Lynn