dnlib | Reads and writes .NET assemblies and modules

However, a metadata token is not a persistent identifier. Rather it is scoped to a specific metadata binary.

What it's saying is that the metadata token is only meaningful within the scope of the module, you can't take the metadata token from one module and use it in another or even within a modified version of the same module (or at least not reliably).

The reason for this makes more sense when you consider what the metadata token really is. The metadata token is a reference to a record in a metadata table within the module, and that record contains further details; the high-order byte of the metadata token indicates the type of token (and thus the table containing the record), while the remaining 3 bytes indicate the row number.

If you take a metadata token from one module and try to use it in another module, you are assuming that the same record in each module represents the same thing. If you compile the same code with the same compiler, then this assumption may hold; but if you change the source or use a different compiler (or different version of the same compiler) then the row numbers may change for any number of reasons.

And why does this problem not occur at all in the method body instructions? Many instructions encode an InlineType and Module.ResolveType has never failed there.

Because the compiler emitting the IL with the metadata token is also emitting the tables into the same file. The compiler is able to keep these things in sync.

And, more importantly, how to fix? How do I save a reliable type identifier in a binary form for the locals of a method?

The only reliable way to reference a type between modules, is with the full type name and scope (the containing assembly, module or type in the case of a nested type).

After a very thorough examination of a dnLib DLL, the problem was due to me using Importer.ImportDeclaringType(Type).ToTypeDefOrRef(), which caused value-type TypeSigs to be registered as class-type TypeSigs instead.

Even though the docs say to use Importer.ImportDeclaringType(Type) over Importer.ImportAsTypeSig(Type) for method and field declarations, you really shouldn't be using it.