ASP.NET Signed assemblies in "BIN" directory not supported?

I ran across an article in the Microsoft knowledge base that really got me worrying: PRB: "Can not Access File 'AssemblyName' Because It Is Being Used by Another Process" Error Message in ASP.NET. The shocker is in the CAUSE section:

CAUSE
This problem occurs because signed assemblies in the Bin directory are not supported.

What? Where is this documented (besides the KB article)? Why? And what versions of the .NET Framework does this apply to? The KB article states it applies to the .NET Framework 1.1 and 1.0 / ASP.NET 1.1 and 1.0, but the article's "Last Review" was on 2005-09-27 - before the .NET Framework 2.0 / ASP.NET 2.0 was officially released. Is the article simply waiting for an update?

Another article that makes one wonder if the .NET Framework 2.0 / ASP.NET 2.0 is affected is PRB: "Access Denied" Error Messages When You Do Not Put Strong-Named Assemblies in the Global Assembly Cache. This article's "Last Review" was on 2004-01-24, but it states that it applies to "Microsoft Web Services Enhancements for Microsoft .NET 2.0". I'm probably being way too literal, but couldn't one at least glance at that and think it applies to the .NET Framework 2.0?

Anyway, Tess Ferrandez writes in her blog "If broken it is, fix it you should":

...strong named assemblies, irrespectively of where they are loaded from are loaded into a shared domain (they are domain neutral)...

...Since the assemblies in the shared domain are not unloaded when the app domain unloads they may get locked if you are unlucky with timing. Locking issues most frequently occur with processes that frequently scan folders such as index server, virus scanning software or backup software...

...If a strong named assembly is used by multiple web applications and each application grants it varying permissions or if the permission grant varies between application domain restarts, you might see errors like “Assembly .dll security permission grant set is incompatible between appdomains”...

That would explain the "Why" (article 813833 makes a similar statement, but Tess goes into more detail). But it's not clear if the .NET Framework 2.0 / ASP.NET 2.0 is affected until you look at the comments, where Tess states:

In 2.0 the assemblies are not loaded domain neutral [...] there was a very specific reason i mentioned 1.1. (and 1.0 for that matter)

and

the issue is due to the dlls being loaded in the shared domain in 1.0 and 1.1. which no longer occurrs in 2.0 [...]

An interesting comment to Tess' post points one to FxCop's AssembliesShouldHaveValidStrongNames rule. FxCop likes assemblies to be signed, but there's nothing that says they have to go in the GAC... Ouch.