> To be clear: I do not use the package system

Yeah, neither do I. So we're on the same page here.

> This is partly because I don't use packages, in general.

Remind me to ask why, sometime.

> And it is mostly because I use multiple versions of Emacs and
> multiple configurations, for testing, and I don't want to be
> bothered with telling package.el what to do and not do each time I
> use Emacs.

I know for a fact that there are alternative package managers which
are designed for this sort of use case, unlike package.el.

> (I would in fact like that to be even easier than now. "Installing"
> packages and enabling them seems too monolithic, to me. It seems to
> assume that a given user has only one set of preferences, which s?he
> uses all the time.)

I doubt this will change soon, as it's a fundamental part of how
package.el works. But that's why we have alternative package managers.

> But in your proposal the first init file is apparently loaded after
> `package-initialize' is done.

The order is:

1. Load package.el init-file
2. Run package-initialize, unless package-enable-at-startup was un-set
   in (1)
3. Load regular init-file
4. Nothing else is done afterwards, unlike currently

> So it sounds like users will have `package-initialize' inflicted on
> them unconditionally.

Wrong. You just (setq package-enable-at-startup nil) in the secondary
init-file, and are never bothered by package.el again. This is much
better than the current situation, where you still have to (setq
package-enable-at-startup nil), but furthermore you have to put an
advice on an internal package.el function in order to avoid
(package-initialize) from being inserted under some circumstances.