Doing more research into the code, I would classify this as a design flaw. The design decision to use this caching assumes that the assemblies that house the controllers and areas are fixed and do not change post deploy. I have a plugin design which allows me to reference assemblies via my web.config.

I simply need to be able to turn this design feature off.
In this way you can keep your original design thinking and allow others to turn it off right at the source.

Proposal:

1. add the following to appsettings.
   <appSettings>
   <add key="TypeCacheUtil:Enable" value="false"/>
   </appSettings>
2. Modify class TypeCacheUtil in TypeCacheUtil.cs
   

public static List<Type> GetFilteredTypesFromAssemblies(string cacheName, Predicate<Type> predicate, IBuildManager buildManager)
{

TypeCacheSerializer serializer = new TypeCacheSerializer();
bool shouldUseCache = ShouldUseCache();
List<Type> matchingTypes;

if (shouldUseCache)
{
    // first, try reading from the cache on disk
    matchingTypes = ReadTypesFromCache(cacheName, predicate, buildManager, serializer);
    if (matchingTypes != null)
    {
        return matchingTypes;
    }
}


// if reading from the cache failed, enumerate over every assembly looking for a matching type
matchingTypes = FilterTypesInAssemblies(buildManager, predicate).ToList();

if (shouldUseCache)
{
    // finally, save the cache back to disk
    SaveTypesToCache(cacheName, matchingTypes, buildManager, serializer);
}

return matchingTypes;

}

forgot ShouldUseCache method in class TypeCacheUtil in TypeCacheUtil.cs

internal static bool ShouldUseCache()
{

string settingValue = System.Configuration.ConfigurationManager.AppSettings["TypeCacheUtil:Enable"];
bool shouldUseCache;
if (!String.IsNullOrEmpty(settingValue) && Boolean.TryParse(settingValue, out shouldUseCache))
{
    return shouldUseCache;
}
//defaults to true;
return true;

}

We've investigated this issue and I've reported the results on the forum thread: http://aspnetwebstack.codeplex.com/discussions/403529

The short of it is:

1. It turns out to be a bug in ASP.NET itself, and we have logged a bug in the Microsoft internal bug database so that it will be tracked for a future release.
2. We believe we've found a workaround for this issue and I've posted it in the forum thread.
   

If the workaround works, we will close out this issue because the bug is not in MVC itself.