What is the logic for the behavior of LV9 when opening vi references?

Question

I recently started using LV 9 and I can't figure out what the rationale is for the LV 9 behavior when opening references to vis. The way I understand it, LV9 looks up vis using the absolute path on the disk where they came from when opening references, even if they are in memory. If just a vi name is given, LV9 tacks on the path of the referring vi on disk when trying to open the reference. So, as far as I can see, either an application opening references to vis needs to specify absolute paths to the location on disk and be modified whenever a dynamically called vi's location on disk is changed, or a dynamically called vi has to be saved in the same directory as the vi doing the calling or in a rigid and inflexible directory structure.  
Example:
I am trying to use a 3rd party library whose vis open a reference to a vi that I create, the name of which is obtained from those in memory using a name pattern. The library vis get the name of the vi I created and try to open a reference to it. Previously this worked because LV looked in memory for "my.vi" when opening the reference but this fails with LV9 because it apparently looks for, e.g., "D:\VI\3rdparty.llb\my.vi", not "my.vi". So, as far as I can see, I have to save my.vi in 3rdparty.llb in order to use it. And, if I want to use 3rdparty.llb in another application, I have to save other vis to 3rdparty.llb or create a new copy elsewhere and save to that copy for the new application. A similar situation would occur if I passed the name of my vi to the 3rdparty.llb vis - either I would need to pass an absolute path and modify my application if I ever want to move my.vi, or save it in 3rdparty.llb.
Another example:
I have a large application built into an executable that calls up to ca. 60 vis  using references.  Previously I could just specify the path to the executable, and I could easily open references to my vis. Now  (if I try to use the LV 9 file structure), I can't figure out the paths I need to open references. Either I have to specify the absolute path to the original location in my development directories, or I have to store all my source vis in some particular directory structure. If I want to reuse my vis in other applications (which I do) things would get pretty complicated. Likewise if I want to optionally open references in other vis than my top level vi (which I do), it seems well nigh impossible.
Basically I am struggling with the concept that an application remembers the directory structure where the source files were located, and/or depends on a particular directory structure of the source files to work. Maybe I'm missing some tricks that would make things easier, but someone will have to explain to me why these are good things. 

Answer 1

I appreciate the responses and explanations. I've certainly learned
some things. I have extensive experience using LV but over a fairly
narrow set of
applications so I'm certainly not aware of many of the possible
techniques.  I clearly don't use LV in the same way as what appears to
be the mainstream for LV programmers.
I have some additional
comments on the various responses:
"But
with VI libraries and LVOOP this had the problem that multiple VIs could
end up with the same name..."
I'm not clear what this means exactly. My first response would be
that it doesn't seem like a good idea in general to use different
portions of code with the same name in a single application. I'm
surprised this is even possible.  I don't think LV will even let me
build from a project in which it finds name conflicts for vis.  
"In addition to what Rolf wrote, it should be
pointed out that LV should NOT be looking for files if you built your
app correctly. Each VI maintains a relative path to all VI it calls and
it should know exactly where to find them (assuming they're there).
I think this illustrates one thing I was talking about. The
assumption appears to be that the organization of your source files is
an essential ingredient in the application that is built, which is a
foreign concept to me. My project file knows where all my vis are, the
applications build correctly, and, using the 8.x and previous file
structure for my exe, they work, and have for some time.  As far as I'm
concerned the main point of using a project that identifies my source
files is to be able to pull in code from different places - if I want to
use a different version of one of my dynamically called subvis, from a
different location, for example, I tell the project file to use the new
version and rebuild.  In your scenario, as I understand it, I'm not sure
why a project file in which you identify source files is even needed, 
if LV already knows everything about the components of the application
you're building.  As I mentioned, my primary application uses ca. 60
dynamically called vis. Most of these control different subsystems of a
large distributed hardware control and data acquisition system. All of
these are used sometimes when the application is used, but pretty much
never all of them at once - typically something like 10-30 of the
user-interactive vis are run at once. There is some communication
between them using globals, queues, and semaphores and such, but for the
most part they are independent and I test them separately. Until the
application is built and used, there is no need to run the entire
application  including all subvis, and I never do it. When I build my
application, the app builder finds all the vis I specify and constructs
the exe file including all the vis I've told it about. Before LV 9 it
never occurred to me that I might actually have to worry about being
able to find vis inside the executable. 
"However as tst has mentioned having an
executable search for VIs is a VERY VERY bad idea as it can break your
entire app if it happens to find the wrong VI at some point."
 I don't really follow this point at all. Where are these vis
masquerading as the ones I want that will break my application? The only
vis on the machines where my applications are used are there because I
put them there inside the executables. I certainly would never use
different vis with the same name in an application - as I said above, I
don't even know if it is possible, and don't want to find out.  Search
paths to find components like shared libraries are a common thing. It
doesn 't seem like a stretch for the run-time environment to define a
default search path like "somewhere in the exe file containing the
application".
I don't want to make a mountain out of a mole hill here, as I said
before, I am happy as long as NI supports the 8.x file structure, but if
nothing else I have definitely learned to appreciate how different
executables built w/ labview are from executables  constructed in other
systems.