It does allow me to keep track of my stages and final location on the server which is nice, and for that reason alone I think it is a good thing.

I do feel that the wording used to tell you how to assign the wps is very difficult to follow at best, and that the limited ability to assign names is frustrating.

In the end though if it helps the approvers (does it?) I’m all for it.

I think there is some confusion here regarding how the prefix, lookup, and description. This is not surprising, as the GC.com documentation is rather poor. Having set up 18 of these recently, here is how it works.

PREFIX – This two letter code is used with the GCXXXX(X) number to generate the waypoint number of the location for those who get gpx files of the cache, using a “prefix plus last 4 digits” algorithm. So, if you are setting up a child waypoint for cache GC1111 for parking, using the prefix PK, the waypoint will be named PK1111. As far as I know, the only banned combination of letters/numbers for a prefix is GC, for obvious reasons. Its possible that WM (waymark) is also not allowed, but I have not tested this.

LOOKUP – GC.Com promises that this Lookup value will eventually replace the “prefix + last four digits” described above in GPX files. I am not quite sure if they can do it, however, because you run the risk of having two or more child waypoints with the same coding. For my caches, I have chosen to copy the prefix plus 4 method for my lookup values, so that these waypoints will not change at all when they get around to “fixing” it. To do this, you have to type the prefix and the last four digits in the lookup field. So I have to type PK1111, TH1111, etc. Just understand that for today, this field is not actually part of the GPX file. Also, note that for non-public waypoints (like finals), it doesn’t really matter what you put in this field, as nobody will see it but you and the approvers.

NAME – You have 50 characters to work with here. This field will show up as a waypoint name in the GPX. If you are using GSAK, or some other program using GPS Babel, to send the child waypoints to the GPS, this field will be sent to the GPS in the Note field (just like the cache name on normal GC waypoints). It is probably a good idea to put something more than “Parking” or “Trailhead” in this field, such as “My Favorite Cache Parking”, so that the waypoint is distinguishable from all the other “Parking” waypoints without having to look at the code to determine which it is tied to.

And, I think these are getting more usage. In my latest PQ for the 500 caches closest to my house, 27 had child waypoints, but there could be a lot more where the waypoints are not public. I believe the approvers have started requiring use of these for new multis and mystery caches.

I too was frustarted at the approval process when I was trying to get my caches approved. However, after my third such cache that required multiple waypoint entries, I can see the value of the listed waypoints as an owner of a cache. It is helpful to have all of the information listed on my cache pages.
To Grouse Tales: How do we go about redoing the prior multicaches to have them all loaded in as is required by current policy? Thanks for letting me know.