rpm -i operation
Desired behaviors:
We want to support the following distinct source types: 
local or remote scm repo (the scm repo management is really all about installing the source into builddir, once that's done, it can fall through to the same build procedure as the next item)
local or remote tarball (yes, this implies that rpm -i on a tarball now makes sense, and it does when you consider that this would really be no different than an installed scm repo checkout)
yum srpm repository (which downloads an srpm and then falls through to the next type)
local or remote srpm
We would like to be able to specify the parameters necessary for retrieval of remote sources in the following ways:
By using a newly added rpm -i --src <binary rpm name> functionality.  In this mode, rpm would use the headers in the rpmdb to determine if the canonical source is srpm or scm repo and would then call out to the appropriate method to retrieve the sources.  Certain command line options listed below would be applicable here as well, for instance it would be possible to specify --latest and get the most recent source on an scm repo branch instead of the exact source representing the installed binary rpm.
By using rpm -i --src <specfile>.  In this mode rpm would act similarly to the previous mode, but instead of pulling the various headers from the rpmdb, they would pull them from the spec file directly.  This allows easy installation of source repos by only having the spec file on hand without having to resort to all command line arguments.
By command line arguments.  The arguments are obviously specific to the type of source you are installing, but they might include:
A valid http: or ftp: URL for srpms
repo type (aka --scm={git|svn|cvs|hg})
repo url (git://, svn://, http://, pserver://, etc.)
--latest (don't get src version that matches installed software, instead get latest for this OS, requires valid branch and pulls head of branch)
--branch (which branch to checkout, ignored if --latest isn't specified, required for command line install of latest software, but will use RepoBranch: tag from rpmdb when installing src for installed binary package...command line will over ride RepoBranch: header when given)
--tag (symbolic tag to checkout, used to get src when not pulling head of branch, ignored when --latest specified, required for command line install without latest option, uses RepoTag: field similarly to --branch option)
Regardless of the method of retrieval, we would like rpm to use the various spec file headers to autodetect if the package is an exploded source scm repo or a traditional style srpm package.  Based upon that it should do one of the following:
For traditional style srpm packages, it should install the spec file in specdir and the sources in sourcedir
For exploded source scm repos, we would like the option of doing a build installation or a cache installation
A build installation would install the repo/checkout in builddir ready to be built
A cache installation would install the repo/checkout in sourcedir so it can be locally accessed instead of remotely accessed for the purpose of repeat builds

Anticipated implementation of rpm -i features listed above:
Installing via yum srpm repo will cause rpm to invoke yum to download the srpm and then will fall through to below.  This option is only reachable by calling rpm -i --src <binary package name> on a package that specifies the SRPM tag as opposed to any of the SCM repo tags.  It makes no sense to enable this option under other conditions as the user can just invoke yum directly.  This is here merely to make --src work on srpm type packages.
Installing a local or remote srpm package works as previous and installs files in sourcedir and specdir.
Installing a tarball now makes sense provided that the spec file in the tarball is an exploded source scm repo type spec file.  Previously, even when building from a tarball, behind the scenes rpm pulled the spec file out of the tarball and placed it in specdir, set sourcedir to the directory the tarball was in, and then proceeded with the build as a normal spec build.  In particular, this meant that if the %prep section of the spec file needed anything other than the tarball itself, such as additional sources or patches, then those files had to be present in the same directory as the tarball or else the build would fail.  This effectively meant that a tarball build was only useful in the case of a very simplistic %prep section that only contained a %setup item, otherwise you might as well pull the spec file out of the tarball ahead of time because you already need more files than just the tarball to complete the build.  However, with the addition of the concept of an exploded source repo with the spec file in the repo itself, a tarball can now become nothing more than a packaged up scm repo checkout.  So, installing a tarball would be analgous to the scm checkout, just without actually doing the scm checkout.  For that reason, we can install a tarball and treat it like an installed scm repo checkout.  Obviously, unless the tarball actually includes the repo management stuff (such as the .git directory for git repos) it can't be considered a full repo, just a single version checkout.  Regardless though, that means we can install a tarball as though it were an scm repo.  As alluded to above, this only works for spec files that are the scm repo type.  If the spec file in the tarball is a traditional srpm style spec file, then we should simply refuse to install the tarball (the tarball could still be used by rpmbuild via the --rebuild|--recompile|-t? methods, but that doesn't effect rpm -i operation and so for our purpose here we can write installing these tarballs off).
Installing a local or remote scm repo depends on scm type and scm options used by the install process (either via rpmdb headers or passed in on command line).  For the most part though, scm repo installation is primarily handed off to the various scm programs and rpm need only direct the clone/checkout.  As such, this will follow a new code path separate from the existing unpack source path used by srpms.
possible optimization: when using a cache repo clone/checkout to create a build repo clone/checkout, then enabling SCM specific optimizations such as hard linked clones, etc. could greatly speed up the build process and also significantly reduce file duplication at the filesystem level.