I also observed the same problem/fix with:

  gnus/message

  progmodes/gdb-mi

  calc/calc-ext

  gnus/gnus-sum

  gnus/gnus-art

More troublesome, though is that emacs segfaulted when it attempted to load nxml/rng-pttrn, whether loading native-compiled, byte-compiled, or source.

Otherwise, I was able to resolve the various issues (including some extensive surgery on vc/ediff-X files to stamp out the circular loading).  I am going to have to do a real bootstrap to avoid the "incoherent eln" error, though, and somehow force native compilation for all the libraries loaded in the dump (that are not on the compiler's "forbidden" list, anyway).

> Btw, you are aware that dumping *.eln files basically dumps just their
> names, not their code?  And that, when you start Emacs after dumping,
> it will load all of those *.eln files one by one, which takes time
> (*.eln files are just shared libraries, like *.so files), and use up
> shared-library and handle slots of the Emacs process?  So I'm not even
> sure doing this would make sense from the performance POV: it could be
> that startup will slower, not faster.

I am aware that dumping the eln files produces an indirection to the shared library, but not the details of the implementation.
I would expect (or at least hope) that the effect of the evaluation that is done on loading to be stored in the dump and for the shared libraries to get loaded into the process without repeating the evaluation.  So things like the order of customization groups should be fixed.
I would also expect that whatever the effect is on the emacs process with .eln files loaded by the dumped file, it is no worse than it would be if loaded as part of my .emacs file.
Another benefit I expect from native-compilation, dumped or not, is more efficient memory use when running multiple emacs processes.  With dumping, I would expect (or hope for) better garbage collector behavior since the amount of allocation required for the loaded modules should be pre-determined (whether byte- or native-compiled).  If the image is 300MB (including the shared libraries), so be it, as long as the memory is shared between multiple processes.  

I'd also like a baseline expectation of performance with native-compiled libraries in the dumped image.  To the extent that dumping verifies that there is no cyclic loading, I can always try the approach to linking I inquired about on this list about a month ago: just catenating the source files together with some minor alterations.  I'm not sure how large a source file the native compiler (or libgccjit) will handle, but it would be interesting to see.

> In any case, I'd suggest to get this working with *.elc files in a
> build without native compilation support, before you try it with
> native compilation.

First I'll see if I can get the ordering straightened out with just the core emacs files required by these packages, then do a test between byte-compiled and native-compiled on those.

Lynn