Late to the party but let me put in my little honest rant.  

I fully agree with the need to better recycle existing content. Some things age. For example: old textures often have burned-in highlights and that's difficult to solve. Poses on the other hand do not age. The parameters may change between figures but they still have two arms and two legs and the direction of the left forearm in xyz space does not change. There are/were perfect pose converters available that can do batch jobs. The poses section of my Project Evolution Runtime has all the poses I collected over time for V4, V3 as well as Schlabber's collections, ready to use with tweaks as needed anyway to match the character.

Obviously conversions cannot be put out as marketplace products, so even when distribution is permitted it has to be as freeware, and as such it does not exist in Rendo eyes. They rather desparately try to market a figure lacking supporting content than actively facilitate existing they do not earn direct money from. I converted manually three pose setsthree pose sets originally by Sclabber to LF/LH, just to see how that goes. It took me an hour or 2 per set to convert.    

Same for clothing conversions and clothing development. LF and LH come with a higher resolution figure as a donor. The problem is of course the geometry is the body shape and not a clothing shape, so copy by proximity leads to bad results, in particular if the figure is muscular or busty. About the bust: shape is usually altered significantly by clothing. You therefore cannot model a nightshirt and a business suit from the same mold. What Rendo lacks is thinking in a system: what would a creator need to make something to work in our system, of which the figure is just one part.   

And about figure textures: why reinvent uv mapping with every figure? After 20+ years there should be some consensus about best practice to skin a human body and spread the pelt on two square tables.  

Time to rethink ways.

The first image shows the lower arm piercing the fabric. This basically nails the fabric to the figure mesh. Then when the lower arm is moved, the whole dress arm is pulled down.

The culprit is too much pokethru of the arm in the starting pose. The cloth room can deal with and solve some amount of poke but not all.

A little theory: Poser does not require collision objects are 'watertight' so there is no way to determine whether a cloth vertex is 'inside' or 'outside' the figure. Instead, it uses a logic that if a vertex is less than a certain distance, the 'collision depth', below the nearest figure geometry it is assigned a force that in the next simulation will push it outwards.  This means that if the vertex is too deep below the surface it will not be pushed out. It means also that if it is closer to the opposite figure surface it will be pulled there. That's why hands, toes, ears and cheeks are notorious for 'catching' the fabric.

Practical advice: use the 'test drape' facility to catch this. It lets Poser do a number of cloth simulation steps while the figure is not animated. You can then check whether the starting phase is correct. In this case you can probably solve by changing the figure pose at simulation start. Do not forget to uncheck 'start from zero pose'.

It looks rather like an issue with the display mode, like you've selected flat rather than smooth, or you do not have 'smooth polygons' selected. 

I would see no reason why it would not work. It is plain Python code, not compiled. I cannot test a.t.m. but I downloaded and reviewed and as far as I can see there's nothing in there that would not be palatable by the present versions of Poser. If there is let me know.

For all purposes and intentions: many uncompiled older scripts just work on P12 and P13 if they are properly coded. It does not hurt to try.

 Cheapest way is FigToProp: https://www.renderosity.com/freestuff/items/86003/fig-to-prop

I will send you an email.  

Thanks. I begin to understand now. The 'dynamic deformation' a mouse action brings would be seen as a displacement within one frame and hence suggest huge velocity. With 'inertia' unchecked, the velocity is reset to 0.0 at each iteration, to avoid the huge energy that would follow from such velocity disturbs the system.  With 'inertia' off a vertex cannot build up velocity so, to the eye of the user, the simulation is slowed down. In this mode you would not be able to 'throw' anything because it would be falling down dead (at constant speed) . Also pendulum motions would not be possible because no kinetic energy is accumulated.

Would it be an option to have this not as a complete switch-off but as a transition? First of all put a limit to velocity and restoring the effect of velocity in a number of frames?  . 

Gotcha! The static simulation stopped when I had completed the thugging. Restarting the sim did what I expected to see. 

Just tried a wrapped garment. Results look not bad at all. Just the piping is disconnecting.

Yes. Indeed GPU simulations (RTX 3070) failed. Good to hear you found a solution already.

I successfully loaded an animation of LaFemme2 and ran a simulation to it. See image below. LF2 is the A-posed variant that now comes with Poser13. It helps maybe to turn off subdivision of the figure. Purging the cache may help too. You may want to ask jroulin. He reported he had a problem with LF in animation and solved it via cache purge. 

This was a very simple dress, just for testing the process. 

Question: if I want to do self-overlapping garments,  like a bath robe or a double-breasted jacket buttoned, do I need to do something special to prevent inversion of the layer order?

Original position was maybe was not the right word. Sorry about that. I simply want the cloth to drape again and not remain 'nailed' in space. Basically I want it to behave like in Marvelous Designer. That if you yank a corner of the cloth, it behaves like a cloth does if a corner is yanked.  

Got it! VWD calls it 'dynamic deformation' and I need to press 'shift' while pulling.

However the cloth does not, or just very slowly, return to its original state.

Got the culprit: u coordinates are flipped on import. VWD somehow sets this.

Ah. I understand the 'active item' must be the one chosen in VWD, not in Poser. That's odd, because one would expect VWD to know which is the 'active-item. 

Anyway. I got the item imported back into Poser. UV- coordinates are maintained, but appear to be reversed. Below shows the cloth before and after draping on the sphere.

First error encountered: When running the 'cloth dropping on sphere' example from the program manual I get an error message:

The active item in Poser is the generated VWD cloth prop.