OK, I figured out everything I was doing incorrectly, along with some idiosyncracies of cpanp custom sources. I think the newness of cpanp, and some things I was doing in a slightly unorthodoxed manner contributed to my confusion.

That said, there are slight incorrectnesses in the handling of versions, which are probably due to my using version objects. When I look at most version numbers for cpan things they follow a N.NN format (zero padded minor). If most people do this, then things will tend to work (I didn't). Another thing that is slightly incorrect is the way things get updated for custom sources in cpanp. Doing "/cs --write file" has the side effect of making "/cs --update xx" work properly. If you don't do this, then it won't work. Also, if you don't do "/cs --list" then indexes don't get created (and you can't use indexes rather than URIs in your /cs commands). That said, most people probably go through the steps in order as they are done in the documentation and so they never see these bugs.

First off, cpanp custom sources is definitely the easiest thing to use if all you want is to maintain your own mini repository of sources. I originally wanted to go the "Mini CPAN route", but have rethought this. There are likely benefits to this, but "cpanp custom sources" is far simpler, and everything seems to work.

There are three basic problems:

1. Updating cpanp's various cached indexes for the custom sources when something changes. If you are changing modules constantly, you'll have to do these same steps each time. Further, this is a non-obvious, multi-step procedure.
2. Build.PL's version should be of the "x.xx" variety, and not the "perl version object" variety. The perl version object supports a wider variety of version styles, whereas the, e.g. "1.05" style is more of a lexicographical version. cpanp makes assumptions as to the version. For example, a version 0.4 will get coerced into version 0.40. If you specify "0.4" in your build this won't match "0.40". The easiest thing to do is to always zero pad the minor number, everywhere. So your version string should look like "0.40" and not "qv (0.40)" which is the newer style.
3. Be careful where you use "::" and "-" as separators. If something requires a "module" (module search, requires), then you want "::".

By paying attention to these details, I was able to make modules and have them work just like all the other modules (e.g. it would find prerequisites correctly).

Updating cpanp's internal caches was non-obvious. Here are the steps required to do this:

1. /cs --add file:///your-dir # only required first time
2. /cs --list # required to set index 1 to your URI
3. /cs --write /your-dir # required to write your packages.txt file for later step, but also required to get new changes to dir. Note this is not a URI but a file, so we are kind of cheating and writing it to the place the URI refers to (another gotcha). If we don't have direct access we'll have to copy the resulting file to the head directory.
4. /cs --update 1 # If you do not do the previous --write step you can see that --update doesn't work properly
5. /cs --contents 1 # verification, make sure your package is there.
6. x # required to update the indexes
7. m Your::Package # verification 2, make sure your pacakge shows up (if you omit 'x' step above you won't see your package.

The cool thing about cpanp is I should be able to script the update step above so that it's done prior to running cpanp interactively.