Proposed Solution
Change the architectural structure of RPM and of the RPM database such that other alternatives besides SRPMs can be used to build a binary package, and such that an SCM repo can be the canonical source for a binary RPM.
The rpm database currently contains a canonical source reference for every binary rpm installed/listed in the database.  This reference is the SRPM: tag associated with the binary rpm and it lists the exact name-version-release of srpm that was used to build the installed binary rpm.  It does not specify where to get said srpm, only what the correct srpm is.  The implicit assumption is that every binary rpm comes from a source rpm.  This assumption would need to change.
We would add some new tags to the rpm database that are set via the spec file.  For any given binary package, there would no longer be an assumption of an associated srpm.  Instead, the package may specify a source repo and a specific, immutable (via policy) repo tag as the canonical source for the package.  In order to support multiple SCM types, the possible list of new tags might look something like this:
SCMType: {cvs|svn|git|hg|etc.}
SCMURL: <repo_url, complete spec for SCMs like git, would be cvs_root for cvs>
SCMModule: <module name for repo types that need this, such as cvs, can also be used to specify a directory to cd into in a git repo so that a single repo can hose multiple projects (not recommended, but can be done)>
SCMTag: <tag representing exact source matching binary package, can be either an easily readable symbolic tag, or can be the SHA1 hash for the tree the package was built from>
SCMBranch: <branch on which tag exists, allowing the installation of later sources instead of exact sources at the user's option>
Given use of the new tags above, rpm could be modified to directly install the sources for any given package by calling out to the underlying scm type via the addition of a new install switch, --src.  This would create a weak dependency on the underlying scm tools in order for the installation of these sources to work, but I believe it is acceptable to attempt the call out and instruct the user to install the underlying tool as needed if the call out fails.  And in the interest of making rpm behave the same whether the source is in an SCM repo or an srpm, we could modify rpm to call out to yum to install the srpm variety of sources.  This would allow a person to install the sources for any package without needing to look up urls and such, but simply invoke rpm -i --src <installed package name>.  Alternatively, the modifications to do this could also be done in yum instead of rpm, but I believe that in the interest of integrating this functionality into a build system, such as koji, the preference would be to do the work in rpm and not in yum.
While it is possible to specify an SCM repo whose contents would be a spec file and all the normal source files such as is the standard in our current Fedora CVS repo, the intent of this change is to allow an SCM repo that is exploded source, and for which no %setup or %patch macros would be needed to prepare the source for building.
The fact that an srpm generally requires a %prep section that contains a %setup and possibly %patch macros, and since an exploded source repo would specifically not use those macros, it would be impossible to create an srpm and a tagged version of an exploded source repo that were both 100% identical and that both would build successfully.  Therefore, I would propose that any given package be allowed to have a canonical srpm source or a canonical scm repo source, but not both.  However, for the purposes of CD distribution and the like, a tarball of the scm repo checkout used to build a package can serve as a substitute for an srpm.