As of 2019/08/21 looking at the BETA (v11) version of the DotNetAssembly Document (https://www.synergex.com/docs/versions/v111/#lrm/lrmChap21DOTNETASSEMBLY.htm) mentions:
 

Although the .NET assembly API supports search paths, we don't recommend that you use them. Search paths only work at runtime, and the gennet40 utility does not support them.

Search Paths (or as we call it Logical Pathing) are defined as a Logicals that contain this form:
 

EXE=C:\MyPath1,C:\MyPath2,C:\MyPath3

When Logical Pathing is used as a parameter to DotNetAssembly the following behavior is observed:

• The FIRST Path that Contains the File Name Will Be Sent to the ResolveEventHandler event (https://docs.microsoft.com/en-us/dotnet/api/system.resolveeventhandler?view=netframework-4.8)
• If the file does not exist in any of the paths the LAST path will be sent to the ResolveEventHandler

Is this expected behavior? If so we request that this behavior be documented.

This behavior is observed by us due to our Interop implementing a custom ResolveEventHandler to allow us to load assemblies from the path containing the DBR Application, NOT The DBR Runtime. (See https://synergexresourcecenter.force.com/SiteIdea?id=0870d000000bppFAAQ).

Furthermore it appears that dbr.exe performs some type of caching on the INITIAL Value of the logical, such that subsequent invocations of DotNetAssembly will used this cached value. Is this expected behavior?

This is important because it is possible (as it is in our system) to have the value of this logical changed during the execution of the program. For us it is not particularly important that this value change (in fact it probably is good that it does not) but it was unexpected from a documentation standpoint.