i think this kinda thing needs to be done on a more fundamental level. freespace has always assumed no more than 3 levels of hierarchy, and all of which is treated as being in the ships reference frame instead of a local one. turrets were either upper, lower or singlepart, in order to simplify the maths.
one problem is many of the pof chunks that contain position data dont have a binding to a subobject (which can contain position, orientation matrix, and a link to its parent's data through a parent sobj num), from which a conversion between world space and any subobjects frame of reference with respect to the entire hierarchy chain and vise versa could be done. the method proposed for engine points for example is somewhat of a work around. on top of that there is no easy method to import transform data from the source model (this data is actually stripped out when the model is converted, this is why you need to reset xform in max). so the orientations of relevant subobjects need to be entered manually, through uvec and svec subobject props. id actually like to see many of the pof chunks replaced by tables, so that they could be made more mutable and upgraded continuously without also needing to update pcs2 to understand new chunk formats.
if for example you wanted to make the primary firing points follow some subobject's rotation, like a spinning ship section, somewhere you would need to tell the game what subobject those gunpoints are relative to. a rotating object rotates because its matrix is updated every frame, so if you multiply the subobjects orientation matrix by the gunpoint vectors (this is called a transform in the graphics world), they will inherit the subobjects rotation. of course this wont wok unless the points are in the subobjects frame of reference, they might wobble because of a bad offset. you would just have to subtract the subobject position from them (this could easily be done only once at parse time) before the points were rotated to the subobjects matrix.
you could could solve the problem piecemeal, each time you need to have something inherit somethings rotation. add a feature and wait for modders to ask the same feature be applied to something else. or you can do it for all of them by adding something like a $inherit parents transform: yes submodel property/table entry. if excluded then the "everything in model space" mentality is used and stuff works normal. on top of this you still need to come up with a way to tell the engine in which submodel the the data in question is attached to. granted you can kinda do some of this stuff in scripting, not that i was about to advocate it for this kinda thing.
If that's the case Bobboau then there is some hope, at least what I had in mind specifically involves more 'sliding' and shifting and less rotating overtly. THe turret's field of fire, if 180 should still roughly be in the same region.
Forgive me for saying, Nuke, I'm not very fluent in scripting and most of what you said went over my head 
. Considering I don't exactly know what the parent matrix is or what it involves with multiplication or a frame of reference. 
then learn how things work in a game engine.
