This appears to be a Windows API bug in LoadPackagedLibrary.

When processing plugins, the runtime strips the extension and just uses the base filename when loading the module, e.g. calling LoadLibrary (WindowsStandalone) or LoadPackagedLibrary (UWP). In the case of LoadPackagedLibrary, according to the API documentation this is acceptable as:

"If this parameter specifies a module name without a path and the file name extension is omitted, the function appends the default library extension .dll to the module name. To prevent the function from appending .dll to the module name, include a trailing point character (.) in the module name string."

However, when the base filename contains a '.' this apparently doesn't work, resulting in a ERROR_MOD_NOT_FOUND error. Unity will work around this flaw by manually appending the .dll extension to the filename in this case.

IMPORTANT:

IL2CPP's implementation of [DllImport] attribute calls into LoadPackageLibrary separately from the Unity runtime, which likewise fails if the module contains a '.' in the name (and the .dll extension is omitted). This bug is being tracked by a different case (1198403). It's possible to work around the IL2CPP bug by simply including the ".dll" extension in the [DllImport] attribute. For example:

[DllImport("Test.Plugin")]
static extern void Foo();

will fail to load the module; "Test.Plugin" cannot be found. However, this will work:

[DllImport("Test.Plugin.dll")]
static extern void Foo();