Instruction making rant

[Daniel R]

I actually took the presumption the "applies to more situations" would be objectionable rather than desirable

That is correct. Nevertheless, there should be some mechanism for all use cases. Maybe there should be different mechanisms, I don't know. These use cases are:

• Simple hovering of parts used in this step
  
• Movement of parts attached some time ago 
  
• Connection of flexible parts ends
  

Unfortunately, sometimes you need to rotate of move several parts which were not a submodel and we not attached in a single step. I am not saying that this should be done using group. In fact, maybe my suggested solution should not support multi-part groups at all. Indeed, this can be done by creating (automatically) one single-part group per part being moved. I only suggested LDCad groups as a way to reference previously added parts.

we'd want to limit ourselves to one ref line per part used (to avoid having to adjust the parts list/BOM, etc.). With buffer exchange, you have to reference each part twice (or more)

I don't quite understand you here, sorry. Perhaps you could elaborate a little bit? 
But yes, my suggestion implies that parts are only moved not added, so no new parts appear in the PLI of the step with movement and the BOM counts should be correct.

Would your MOVE GROUP command have some way to handle multi-step hovering, or would it just not allow for this possibility?

Yes. My suggestion is that you first add you part in the hovering position (and it is counted for that step's part list), then you add a step or a number of steps (maybe even finish this submodel and go to the outer one), then you decide that part should be moved, then you switch to "move mode" of LDCad and move the part as if you were just adjusting its original position. LDCad then would add a group definition to the step the part originally appeared and a MOVE GROUP meta to the current step. When you would go to some following steps, LDCad would keep track of all MOVE GROUP metas and display the part in its correct (updated) location, very similar to the way it currently handles buffer exchange.

Yes, of course either the software or the user would have to keep track of that. Of course, the parameter would be configurable, so at the end of your workflow you could easily adjust a part's float settings

Maybe you could explain how that interface could look?