This iteration of pactool won't support that, my remake sometime in the future will. I'm currently trying to figure out of the cut data myself.
The structure so far is 1 byte to indicate how many cut "groups" there are and then each group has 1 byte to define how many "positions" there are 4 floats (4 bytes each) long, with current research it seems that the "positions" are actually defining a normalized angle with the last 3 values, the first value is still somewhat of a mystery, in-game the values seem to create "infinite" planes where on one side the mesh stays and on the other it is cut, when "positions" intersect they're no longer "infinite", so with multiple planes you can define different shapes to generate a cut for a very specific area.
I've also confirmed that the bounding box defined right before the cut data (6 floats, lowest X/Y/Z followed by highest X/Y/Z in the mesh, pactool does not update this, which is why cuts don't change with meshes that are supposed to have smaller/bigger boxes, if you do update it, the cut changes).
Also the "groups" cut meshes defined in partcutdesc, a "(Basic)CutType" group has two roles, first it defines a list of files to cut by other meshes, but the group itself can also define whether the listed meshes should cut others, assigned by the "Relation", for example meshes listed in "Underwear" have a relation to cut "Nude" which lists the characters' bodies, I believe that the order of the cuts listed in the relation correlates to the index of the "groups" defined in the pac data.
