What is the best way organize a solution with shared nested (SVN External) project files?

Question

So a little bit of history; I maintain a svn where, various repositories for applications and shared libraries all sit off root of the server

• root
  • App1 (depends on ORMthing, UIstuff, Common1 )
    • trunk...
  • App2 (depends on ORMthing, UIstuff, OtherStuff )
    • trunk...
  • ORMthing (dempends on Common1 )
    • trunk...
  • UIstuff
    • trunk...

Originally, when a project depended on another project and made part of another solution, I used relative paths to walk down the folder tree and back up into my desired repository. This worked well enough because I could keep my working copies anywhere as long as they shared a common root path. Unfortunately I would have to go in and change all those relative paths whenever I wanted to create a branch, and some of the people that need to access to these solutions aren't very savvy.

So my solution: Use SVN external properties to nest the solution folder of referenced projects within my solutions. There would still only be one copy on the server, you can pull and update all the files required to build a solution with one SVN checkout, and it is easy to switch a referenced project from the trunk to a branch with one SVN switch command.

However there appears to be a problem when I have a situation like App1 above where it shares a common dependency with one of its other dependencies, ORMthing.
When ORMthing goes to compile, Visual Studio doesn't recognize that although Common1 is already part of the solution, ORMthing expects to find the dll for Common1 where it normally is, relative to ORMthing's project file. However this appears to be a bug the build process. When I look at the path property for ORMthing's reference for Common1 it shows the target path for the project that is owned by the solution and directly referenced by App1.