This sounds like a maintenance nightmare when you start juggling lots of code.
A simpler solution might be to put your custom modules in node_modules (without symlinking) and then commit those to your source tree.
The main point that I wanted to get across was that it's worth structuring your packages in such a way that makes it easy for developers to write new modules without using a lot of relative paths in the file system. Node does this work already, so I like to take advantage of it.
git submodules are designed to solve this problem and do so very well, allowing each project that uses a shared module to include whatever version it pleases, yet allowing the project using the shared module to update/rollback to a newer/older version.
"[$NODE PATH exists] mostly for historic reasons. You are highly encouraged to place your dependencies locally in node_modules folders. They will be loaded faster, and more reliably."
http://nodejs.org/api/modules.html#modules_loading_from_the_...
> ...small shared library files that don't justify their own package.json...
Generating a package.json + dependencies is a 30 second job with npm init + npm install --save + npm link. I follow a similar pattern to you when developing inside a single module, where I start growing module saplings in a ./lib folder to spike on ideas without the overhead of totally decoupling from the parent, but as soon as you need to share that code around and put it into your $NODE_PATH, you've got to decouple it anyway, so really you're effectively 30 seconds worth of work away from creating a real module anyway, and thus you could do away with your custom $NODE_PATH.