I didn't see your SOP Import settings in the .hip file, but I think you just need to enable the Subset Groups toggle and set it to * if you want to import all of the prim groups back to USD geometry subsets (see attached file)

I think either should be okay - the main thing to check, if you're using the crowd solver, is the 'pscale' attribute value which affects the size of the bounding sphere used for avoidance

In this case, if you're not actually needing to write to P you can remove it from the "Attributes to Create" list

If you did actually need to write to it, changing the POP wrangle inputs to "Myself" instead of "Myself (no reads of outputs)" would normally be the solution here, since you can't safely read from an attribute on other points in the geometry that is also being written to when multithreading is involved. But that doesn't work here because you're using a string path that happens to be the same as the geometry being modified ("op:/obj/crowd_sim:crowdobject/Geometry") rather than the 0/1/2/3 or @OpInput0 etc inputs

The Glue Adjacent tool wouldn't have worked with the RBD solver since it creates constraint networks For the RBD solver I think you'd have to use the Glue to Object parameter on the RBD Object DOP to set up the old-style glue

USD variants would be a possible encoding, yes. Currently SOP Import creates a multi-reference since an agent primitive (as of 19.0) can have an arbitrary number of layers assigned to it

If you have the static object's geometry in SOPs, with a name attribute assigned, then tools like RBD Constraints from Rules, or even just Connect Adjacent Pieces, can be used to create constraints between your fractured object and the static object

UsdSkel is a schema for describing skinned characters, not for representing an agent definition. So, things like agent layers, transform groups, clip library, etc will not round-trip 100% as they don't have a USD representation. For caching an agent definition, you should just use the Agent Definition Cache SOP if you want it to be exactly preserved

For more fine-grained tracking of geometry changes, you probably want to use data ids [www.sidefx.com] to see whether the attributes or topology you're using have changed

For the second question, that approach is safe. The same SOP_Node instance will not be cooked from multiple threads at the same time.
Note that if you implement a verbified SOP (like the SOP_Star example) the verb can be executed in parallel with different inputs, e.g. in a foreach loop, but in that case you'd use SOP_NodeVerb::CookParms::cache() (after implementing SOP_NodeVerb::allocCache()) to get a unique instance of your cached data as required

I'm not familiar enough with value clips or whether they have any limitations with skinned primitives, but perhaps try looping the deformed geometry instead?

I don't think this is supported by Hydra on the rendering side of things. A workaround would be to use the BakeSkinning operator to bake out the skinning to a deforming mesh, when then can be instanced.

The underlying reason for this behaviour is that when you import multiple prims which have different values for the same detail attribute, the stricter merge used when unpacking packed prims will promote from a detail to a prim attribute to avoid losing those values. The Unpack USD SOP chooses to always import constant primvars as prim attributes because of this, so that the attributes don't unexpectedly change from detail to prim depending on whether you're importing other USD prims - that behaviour was problematic for downstream setups that expect attributes to be in a certain class. The downside is that you do need to promote back to detail attributes if your setup requires them and you're only importing one prim

usdconfigconstantattribs is recognized by SOP Import (like attributes set up by the USD Configure SOP) so that those attributes can be round-tripped back to USD as constant primvars

There is also an RFE #124148 for allowing constant attributes to be imported onto packed USD prims as you mentioned.

I think you might want to have `Cook Frames as Single Work Item` on, since you want to generate a single USD file with the time samples from the whole frame range?

Correct, there isn't a way to revert to the old behaviour, unless perhaps if you adjust the attribute's tuple size temporarily while debugging. It's always enabled for float attributes with a tuple size of 9 or 16
You might also find it useful to enable "Decomposed Matrices" in the spreadsheet's View menu

qconvert() returns an angle/axis vector, where the vector's direction is the axis and the magnitude is the rotation around that axis

You might be looking for quaterniontoeuler() instead?

That error should be uncommon, and probably indicates an issue with the collision shape or rotational stiffness settings.
The file (either uploaded here or sent to support) would probably be needed to see what the cause is for your particular case

Attribute Rename just renames the attribute itself, not the attribute values
It sounds like you want Attribute String Edit, which can be used for index-pair attributes like boneCapture in addition to regular string attributes
There's a note at the top of https://www.sidefx.com/docs/houdini19.5/nodes/sop/attribstringedit [www.sidefx.com] for how to edit the capture region names for boneCapture

When the rotation limits are zero for an axis, it's generally better to use the Rotation Weights parameter to disable the axis entirely, rather than using rotation limits (see attached)

Yes, it is possible. The main place where you run into anything quadruped specific is for setting up foot planting / terrain adaptation
For example, https://www.sidefx.com/tutorials/advanced-crowds-quadrupeds-dynamics-and-how-to-work-with-problematic-assets/ [www.sidefx.com]

Yes, you should be able to add all of the skinned shapes to the agent. The "Geometry" video from https://www.sidefx.com/tutorials/h19-crowds/ [www.sidefx.com] might be a useful reference

Blendshapes are supported - attached is a simple example.
It's hard to tell from your video, but since there aren't any USD BlendShape prims being created under the mesh I would guess that the skin geometry you're pointing to from SOP Character Import is from the output of the Character Blend Shapes SOP? It should be the input skin geometry (without blendshapes applied)