Every once in a while I find some code doing something similar to this:

new NamedPermissionSet("LocalIntranet").Assert();

// ... call some API that requires Intranet permissions here

CodeAccessPermission.RevertAssert();

At best this code is confusing to people reading it, and at worse this code is actually doing something very different than what the author is intending to do.

The trick here is that NamedPermissionSet has two constructors, one which takes just a name, and a second which takes the name and a PermissionState value.  In neither case does NamedPermissionSet actually look up the permission set that you gave it.  Instead, the constructor which takes just a name initializes the permission set with the name and PermissionState.Unrestricted.

Yep -- the code above creates a FullTrust permission set, which happens to share the name of another well-known permission set, but in fact is an entirely separate entity.

As an extra twist to this story, the PermissionSetAttribute will look up a known named permission set -- so doing

[PermissionSet(SecurityAction.Assert, Name = "LocalIntranet")]

will work as expected.

If you really want to have a FullTrust permission set, then newing up a NamedPermissionSet with the name "FullTrust" will work -- but for the reasons above, not because you gave it the name FullTrust.  For this reason, I tend to avoid that construct, since it can be misleading -- it would be far to easy to just switch the name in maintenance and think that you've changed the permission set itself.

(If you really want to get one of the built-in permission sets, check out this blog post for some sample code).