> The main benefit of such API would be interoperability between
> package managers.

So to be clear, I like this proposal. But I'd like to ask whether it
will really offer a lot of benefit over the current situation.
Specifically:

> allowing for complex cases like when you want some package from
> package.el, then other packages from some other package manager,
> then other packages from package.el.

Why not just say it is the responsibility of the package manager to
let the user say which packages it is to make available and which
packages it is to leave for another package manager? That seems more
flexible and natural to me.

> dealing with autoloads

Indeed, this seems like a big problem. Because a package can run
arbitrary Lisp code in its autoloads, and the user expects this code
to be run unconditionally when the package manager makes the package
available (and in particular, *not* when a feature is required). If we
have the package installed via two different package managers, then
the only way to do this correctly seems to be to tell the package
managers which one of them is supposed to activate the autoloads --
and then we are right back at the current situation.

Would this require a restructuring of how autoloading works in
general? If so, the resulting loss of backwards compatibility
indicates that there need to be some concrete benefits to the new
approach.

                              ~~~~~

Another thing I worry about is whether this is the right abstraction
for package managers that operate in different ways than package.el.
For example, in the package manager straight.el, there is no concept
of an "installed package". Instead, you specify to load a package
declaratively in your init-file, and it is downloaded, built, and
loaded automatically if necessary. One important point here is that
the package is automatically rebuilt if it has changed since the last
init, and the process of checking for modifications takes some time.
If you care about your init-time, you probably would only want
straight.el checking for modifications to packages that it actually
loads (rather than ones loaded by a different package manager), so
straight.el must be made directly aware of which packages it is
actually supposed to load. Once again, this brings us back to the
current situation.