The .edata section of a Dll contains, besides the individual function exports specification, a field that specifies the name of the Dll (see this reference, field "Name RVA"). In all the documentations that I can find however, the resolution of imports always refer to Dll file names and paths, and of course these can differ from the "recorded" Dll name as specified in this entry.
What is the purpose of this field? Does it have any role in the resolution of imports?
When debugging raw memory, the filename (and path) from which the DLL was loaded might not be readily available and this field from the export table is a handy way to identify that a particular region of memory is occupied by a particular DLL.
Beyond its debugging value which is reason enough for its inclusion, the Windows loader may also use this field when recursively resolving imports to determine if a particular module is already loaded or as a security sanity check for system DLLs, etc. Even in the case this field were completely ignored in modern versions of Windows, the PE/COFF spec at least provided for this possibility.
To answer your question directly, this field has no role in the resolution of imports - at least it didn't use to. It is possible this has changed in recent versions of Windows, but it would break backwards compatibility if it applied to non-system DLLs. My guess is that this field remains ignored for any type of import resolution whatsoever.
For fun, I ran a quick test using 32-bit PE modules on a Windows 7 (64-bit) machine using this criteria:
Both versions of the private DLL loaded successfully when I launched the test EXE, as long as the test EXE's referenced import section had the correct filename the DLL happened to be named at the point of launch.