As far as I know (and I could be wrong) VB6 does not actually use those paths for much of anything. Instead it uses the TypeLib GUID and version to look in the registry and locate the file containing the type info. Then it updates the path, which it only uses when you save the VBP again.
Perhaps the only time this path is ever actually used is when the typelib & version cannot be found in the registry. This may trigger VB6 to try re-register the library using self-registration entrypoint calls based on this path.
If this is incorrect then what follows doesn't apply, though this is how things work generally anyway:
It seems far more likely that your problem is that VB6 and/or these (3rd party?) libraries were never installed properly.
If a library is not registered globally (HKLM) then each "new user" (new on that machine) opening such a project will trigger a re-registration attempt based on the path in the VBP file. If it fails they will have a broken reference problem.
Correcting this manually by navigating to the library causes the side-effect of re-registering the library for that user in the registry virtualstore if VB6.EXE is not running elevated, making the problem appear to go away for that user. If running elevated then it should "cure" the problem for everyone on that machine from there onward. It isn't a true cure, since you have orphaned junk registrations in various users' virtualstores which can bite you in the future when libraries get updated.
VB6 and libraries it will use need to be installed while fully elevated: their pieces and parts need to be stored in non-virtualized folders and components must be registered in the non-virtualized HKLM hive.
VB6.EXE should always run elevated and will be most reliable if this has been done by applying an application manifest to accomplish elevation, which prevents legacy app virtualization.
WOW64 registry redirection is a separate topic. Since VB6.EXE is 32-bit software that should operate transparently.
