Hi Dave,

Without another appdomain , I think to recall that someone suggested for
this problem to read a stream of bytes from the assembly (via IO) and then
load the assembly using the overloaded variation
System.Reflection.Assembly.Load(ByVal rawAssembly() As Byte). That should
not block the assembly on disk.

Thanks to everyone for their help and input.  I did come up with a solution,
via a combination of the info obtained here and some detective work.  I
managed to avoid (barely) the use of the unmanaged metadata APIs.  Let me go
over the solution, just in case somebody else runs into this issue in the
future.

First thing is to have your build task Execute() method make copies of the
non-GAC assemblies referenced by your project instance.  These should all be
under a common directory.  Then create an AppDomain which sets that directory
as its application base:

AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = fullPathToDirectoryContainingReferencedDllCopies;
AppDomain myAppDomain =
        AppDomain.CreateDomain("Compiler AppDomain", null, setup);

The compiler itself needs to run in that AppDomain, so that reflection can
properly resolve all type references for type resolution (note that the set
of referenced DLLs needs to be closed).  Thus, when A.dll references a type
in B.dll, when you reflect on A.dll the runtime can find B.dll.  Running the
compiler in the separate AppDomain requires that you use one of the
AppDomain.CreateInstance methods to make an instance of the compiler.  I used
CreateInstanceFromAndUnwrap, providing the full path to the compiler's
assembly, because that's the only way I could get it to work.  .  

Note that in order to be able to reference your remoted (cross AppDomain)
compiler instance from inside the VS process, the compiler DLLs and any
dependencies need to be somewhere under the VS app base directory.  I put
mine in <VS Install Dir>\Common7\IDE\PublicAssemblies.  This required a
post-build step to copy the VSPackage and its dependencies to that directory,
as well as redirect the RegPkg step to the appropriate dir.

The final piece of the puzzle was loading the project reference assemblies
into the compiler's AppDomain.  Recall that my original question had to do
with avoiding the lockup of those DLLs after the first build (they presumably
got locked because the VS AppDomain held a reference to them).  I tried just
loading the assemblies via Assembly.Load(), and then unloading the compiler
AppDomain when the build was done.  No luck - the files were still locked,
which seems weird (in fact VS showed the relevant modules as being unloaded
after tear-down of the AppDomain, but the files were still locked).  I next
tried Carlos' idea of first reading the assemblies to a byte array, and then
loading into the AppDomain.  That almost worked, except that when A.dll
referenced B.dll, B.dll get reloaded by the runtime, and then was locked
anyway.  Bleah.

The solution turned out to be using Assembly.ReflectionLoadOnly().  
Apparently this has some memory, so dependencies are also loaded as
ReflectionOnly, and the whole locking thing is avoided.

Thanks again to everyone for their help.

Dave