> > Would a ~/.emacs.d/.package-initialize.el file, to be read by
> > package-initialize before it does anything else, be a better
> > alternative for configurations that must be done before
> > package-initialize is called?
>
> To me, it'd be a worst case fallback if we can't find a better
> solution.
That's a reasonable perspective. I personally do think that there is
no better solution.
Also, I really like the naming and the idea that the file is loaded by
`package-initialize', not directly by startup.el.
> Change package-initialize so it keeps track of what it activated and
> if called a second time, perform a diff between what was activated
> before and what should be activated now and based on this activate
> the new pkgs and deactivate the excess ones?
This will introduce performance regressions. Besides, having one part
of the init process undo a bunch of stuff that a previous part did
seems like a sketchy design to me. Also, it's impossible for this to
work correctly in general since autoloads can run arbitrary Lisp code.
> Process ~/.emacs specially so it can start with a special construct
> (with-early-config ...)
That seems like a hacky way to try to combine two files into one file.
Wouldn't it be better to just use two files?
> I've had other ideas, but they generally suck one way or another.
Me too. For example, I now think that my original idea of generating a
template init-file is a less effective solution than
~/.emacs.d/.package-initialize.el.