I've encountered very severe limitations as far as how to manage the HDA processor, it's essential to the pipeline/workflow here. Basically we've got a very complex set of nested operators stored in a single .hda for a macro operation, and then the idea is that the hda processor will go at some of the heavy geometry processing. Long story short:

1. I need to make sure the shared drive __PDG_TEMP__ has access to the .hda file
2. I need to select the correct definition and type (sops)
3. I need dependent assets included

Problems encountered:
a). When using the full set of .hda/types, it selected the wrong node, since it defaults to select the first one available
b). When I use a definition with a single type, and try the "include" files, it copies the .hda's over but doesn't install them on run
c). When I use only the type and the nested assets in the same hda file, there's more success, but this is probably random because it's still probably selecting only the first file, and if so .. how do I name them or sort them to where the correct definition is guaranteed to be the first file?
d). I tried using variables "hda" and "operatortype" however, to set them directly in an attempt to avoid the problem all together. However, this errored. I'm not sure what formats or data these settings expect.

Ideal Solution:
1. All included hda files are installed before processing
2. The operatortype is set from the template node or, it's able to be typed, and/or overridden by a pdg attribute

Solutions?
Is there a more ideal workflow for the issue's I'm encountering? Thanks!

There were some changes to the HDA Processor for a different RFE that may address your issue with the operator type. It's now possible to set it with an expression, since it's no longer bound to the .hda file path. Those changes will be live in tomorrow's daily build of H19.0.

For the other items, please log an RFE or Bug with an example .hip/.hda file that demonstrates the issues at hand.

Awesome can't wait to try it out!