Since the effect is to be skin tight makes it much easier to do.  Maybe add a couple of morphs to smooth the ankle etc. and be done.

And if you use a second skin effect much like the painted on Bra that V4 wears then you change the length of the mask and that changes the height of the sock.  And it follows the bending just as the model since it is the model.  Different masks can be made to make parts see thru such as fishnets.  About the only thing you need to make is a toe cap to hide the toes the rest can be a texture map.

Is there a reason why you don't want to make V4 legs invisible?  The whole concept that we have to leave every single polygon visible and hope to make two objects mirror each other with the perfect amount of offset to hide one set of polygons that should be hidden is a massive waste of time.  You have to ask yourself what is the final result suppose to be?  If you turn off the visibility of the legs then the poke thru would be gone. In this case the best way to do it is to make a mask to turn off the texture under the sock.

The real simple reason is that the programmers are convinced that TRUE Unimesh will solve all the problems.  The problem of course is that there is no defined outcome that Unimesh is suppose to be.  The basic one (which several scripts have been created take care of) is being able to Export an Object file and be able to use it in a modeling program and bring it back in as a FBM.  They work great in Poser BUT for some reason DON'T seem to work in other programs, or at least that is the excuse that I have heard. 

The problem is that the Unimesh the programmers are trying for will get rid of the splitting of the figure and only work with it as a single mesh.  Ignore the fact that Poser has worked with split Mesh for the last 25 years.  Also that a great amount of content is only in split format (as the original object files are long gone) so the problem is how to recombine all those split scenes and make it so that it will work in other programs (for what reason unknown).

The simple solution is to load the object as it is now doing, HOWEVER, Keep a copy of the original obj and also split as it currently does.  It would be a piece of cake to create a cross reference table that tracks each vertex so that when a vertex is moved in the split object it is updated in the solid object and visa a versa.  And when it comes time to export (or save) use the solid object.  Since the solid object has not changed order or number of vertices it remains exactly like the original with just the vertex's moved in space.  That way very little has to be done to the program and those functions that work best with split mesh can work with that and those that like solid use those.  About the only thing that wil take a bit of change is rendering when part of the model is removed (such as the forearm).  

The scripts that usually fail are those that are compiled PYC.  If they are left uncompiled they should work unless there is a change to the syntax rules, and even then, it would be  fairly simple to fix the error.  If not the that user then they could ask and someone can give the fix in a post.  The same thing happened to PE when Poser 11 came out.  The script was setup to work with Poser 9 OR Poser 10.  By changing a single line in the script it was possible for it to work with 9 OR 10+.

The other thing is that Preview is limited to FireFly only.  If you have ANY SuperFly nodes in the material room that will effect the Preview engine.  If you only have FireFly nodes you should have no problem.  

According to the IT department at work a shortcut can be created if you click and drag a file.  I was selecting files and my mouse would unclick and ruin the move I was trying to do.  So somehow I managed to fake windows into thinking I wanted to create a shortcut and so it did inside my Pose folder.  And when Poser runs it looks at all the folders and files inside the runtime to try and build the database of assets.  A shortcut is similar to but not exactly like a file and when Poser try's to read the information for that item it returns garbage and Poser freaks.  So most likely Poser thought it was a Folder and tried to open it to see what is inside and that is where the error is since the shortcut is not in the path that Poser was walking down when it came upon that shortcut.

Well I found what was causing the error issue on my computer.  When Poser was opened by clicking on one of the pose files somehow it also managed to place a shortcut file inside my Pose Folder. When i renamed Pose to XPose then Poser created a new Pose folder and did not have the error issue.  So I moved the files from the XPose over to the new Pose and would try Poser every once in  awhile and it did not error out.  When I got down to the last sets of Files I noticed the Short-Cut in the XPose folder and when I moved that file over the error came back.

@Gage I would look in your folders inside the bad runtime and see if you have any windows short-cut files.  Mine was for the My Documents folder, yours will probably be that folder on the end of your error message.  Remove that short-cut and things should return to normal.

Further testing and it appears that one of the folders in the runtime is the cause.  I tried to rename the folder and that failed.  Then I copied the entire folder to a NAS storage box and copied those files back to a new folder and still get the same error when I attach that new folder to the library.  So to me that says it is a setting on one or more of the folders or files in the runtime.  It would need to be something on a higher level as the error pops up with in a couple of seconds of attaching the Runtime.

Next will be to rename all the folders inside the runtime and see which one causes the issue.

 So, I just did the same thing that you did.  I was moving Files around in a runtime and the mouse took the click as a double click and opened Poser.  I closed Poser and continued to move files around.  Now whenever I open Poser I get a message much like yours.  you have to edit the LibraryPrefs.xml and delete the runtime that is causing the issue.  If you have Poser open and click on the remove library option it will list all the attached runtimes.  There are a couple you cannot remove and they are grayed out.  Also it appears the one that is the cause of the error message is also grayed out.  That makes it kind of easy to find.  The long term fix is something i am now working on as it appears to be a windows file time issue as Poser cannot find the time of the folder so that is the root cause..

I will be doing some more tests but at least you have an idea of where the problem is. 

Have you tried to rename the LibraryState.xml file?  It stores the open state of the library folders and you may have saved it when you closed and it is now trying to re-open something that may not be possible.

The eight light limit is in opengl and as such is not possible to get around directly.  About the only thing you can do is render the first 8 lights and then select then next 8 lights and finally composite the images together.

Here are two Andy's with Flat Shaded on the Left and Texture Shaded on the Right.

Also, under the properties tab you can change the subdivision level in Poser 2014. If it is a Figure you must first go to Figure-->Skinning method--> Poser Unimesh

Layers has been broken since Poser 2014 and really should not be used unless you are doing something like a walk or talk design.  Then the layer is a total replacement and done for each frame and it is in replace mode.  Otherwise, best to ignore that feature.  I used it a lot in Poser 2012 and it had some small problems, but 2014 and later are broken and there have been a number of tickets put in about this issue.