#:deep? #t currently works by interposing a dummy build system that
lowers the package to a bag using the original build system, then
applies the supplied transformation to all of the bag's inputs, then
returns a new bag with the new inputs.

The problem with this approach is that it doesn't affect the bag
arguments.  This means that packages passed in as arguments may still
end up being used without being transformed.  Worse still, packages
*not* passed in as arguments may end up being used *unless one is
explicitly passed in as an argument*, as is the case with
qt-build-system's #:qtbase argument.

In short, the current approach of having the build-system lower
procedure leave the arguments mostly unchanged and letting the
bag->derivation procedure (the "bag builder") fill in lots of defaults
means that there are implicit inputs that cannot be touched at the
package level without adding special logic for every single build system
that does something like this.

I propose that we have the build system lower procedure (that is, the
one that converts from package to bag) completely fill in the argument
list with all defaults, and we modify build-system-with-package-mapping
to transform all arguments that look like a package or a list of
packages (or maybe even a tree containing packages).

Many large-scale package transformations have their purpose defeated if
even a single package slips through and has to be built or downloaded
separately (e.g. "I wanted to use a more minimal version of P, and now I
have both the original version of P *and* a more minimal version of P
*and* a duplicate copy of a large portion of the package graph...").  In
fact, in some situations, this could cause exponential growth of the
number of packages, e.g. a transformation is applied to qtbase and its
dependencies, but not to the implicit version and its dependencies, so
now all the dependencies of qtbase are duplicated, and if this happens
again at a higher level with something that depends on a package with
qt-build-system, now there are four duplicate subgraphs, and so on.

What do you think?

- Ulf