There is something odd in the Closest Point operator. It comes up most commonly when using it to transfer texture coordinates, but can come up any time. There will be verts that do not properly receive the closest point data. I will try to put together some examples when I can. But to resolve these issues I have started creating vertext point cloud PRT’s of the mesh I want to find the closest point on and am then using Closest Particle. This always seems to work perfectly without odd vertex artifacts. So this got me wondering. Could you do a closest Vertex search and pull data off of it as if it were a PRT file. I mean, Krakatoa generates the PRT data from the object and its verts, if Genome could just query this and bypass the need of first generating PRTs of the geometry verts, it would save a lot of time and it seems to generate more consistent results. The Closest Point op would still be useful when you really need the face level detail (barycentric relative data). Anyway, just some thoughts.
I’m not familiar with any issues with ClosestPoint (on the other hand I know IntersectRay will miss a triangle from time to time). Can you post a screenshot that indicates what “do not properly receive the closest point data” looks like?
Closest point doesn’t really have anything to do with vertices…
The closest point on a mesh can be a long way from the closest vertices. think of a bolt head on a large flat polygon. A point beside the bolt could have thousands of verts next to it (the ones in the bolt head) which aren’t relevant because the closest point lies on the large flat polygon whose verts lie miles away.
R
…which is why I am asking for the option to use closest vert. 
Although, closest point by normal might also help alleviate these issues sometimes. Anyway, here is a scene that I believe is showing the problem. It doesn’t always come up, but when you are animating the objects it comes up a lot more often. Another place it frequently comes up is when I am upressing a fragmented mesh and trying to pull the uv’s back from the original mesh. In those cases, the problems seem to crop up near sharp angles in the topology. In the attached scene, if you move the box around you can see the artifacts dance around and if you change the vert counts on the objects you can get them to be worse or go away altogether. But sometimes it is difficult in production to find the sweet spot where it all goes away, especially when both objects already have a lot of verts.
genome_closestPointIssue_001.zip (51.5 KB)
2013 file
According to the Magma documentation, the Distance output of the NearestPoint has a negative sign when the point is seen from the back side, and positive when seen from the front side. So in your case, some vertices find a backface point to be closer to the facing polygon. I am not sure if this is a bug or if there is actually a case where that is possible, but it obviously does happen. I believe it happens when the vertex is nearly in the plane of one of the faces, and it believes to be looking at it from the backside (could be due to rounding errors, I am not sure).
You have two options, both do the same, the first is much easier:
*Drop an ABS operator between the NearestPoint and the Divide.
*Subtract the ToWorld from the Position output of NearestPoint and output the Magnitude to the Divide.
Hope this helps!
Thanks Bobo. That does help. 
This has got me to rethink my methods for the UV transfer, and I am already getting more predictable results.