I was planning to use the delaysign facility from the get-go since besides
the hack you provided, there is that added benefit of having only certain
individuals maintain the private key(the main reason for me).

However, what I would really want is not to have to use GAC at all even in
the production.  Here's my situation:

I am developing add-ons to an already existing ASP.NET application.  The
application is a website in itself and my add-ons would simply be subfolders
underneath the app root.  I would rather not have to create virtual folders
for each of my add-ons if I don't have to.  The structure of my add-ons is
that there is a single folder underneath the app root so that all my add-ons
are located nicely in a single folder from the perspective of the
application.  The folder would contain common files, resources, pages,
assemblies for those pages in its own bin folder.  Then there would be
subfolders underneath that for each add-ons.  The add-ons would themselves
have their own files, resources, pages, assemblies for those pages in its
own bin folder.  Normally, ASP.NET would only look for assemblies in the
application root's bin folder.  I added <probing> element in web.config to
get around this so that the ASP.NET runtime now finds my assemblies in
folders other than the application bin folder.  The only problem is that
this does not affect the ASP.NET compilation step, meaning the codebehind
base class which derives from Page and the assembly that contains it, must
still be found in the application bin folder since that is the only place
ASP.NET will look when compiling your <pagename>.aspx.  That means I have to
put all those assemblies in the application bin folder.  So why is this a
problem?

We come back to the versioning issue - and perhaps the reason I need to use
GAC after all (YUCK!).  If I deployed, let's say, 5 add-ons to a particular
app, and later find that I need to update the common platform assemblies
(add-on specific assemblies are ok since they won't collide with each other
anyway because of their names(even the short) will differ. i.e.
Com.Infinity.App.Addon1.Web).  This may happen when you make some changes to
one of the add-ons and while you're at it make changes to the common
platform to support new features, changes, etc.  This happens and while you
try not to break any dependencies, sometimes it's unavoidable.  If I could
put my assemblies in other than application bin folder, then, by simply
configuring my web.config, I can put the newly updated platform assemblies
in the particular add-on's bin folder so that it only affects that add-on
and leave the other 4 add-ons functioning.  Now, leave any arguments
regarding my update schemes, assembly versioning faux pas, etc. aside for a
moment.  Being able to specify different location for assemblies for each
subfolder would be nice nonetheless - a la web.config.  AND it should use
that location for both compile time and runtime.  As it is implemented
currently, the only way to do that with ASP.NET is to use the GAC.

Sorry about the rant.
You've been very helpful!