if your command is not targeting a huge audience, I recommend to split it into to steps or more.
_FancyEditInit (generating the helper-geometry to edit)
_FancyEditUpdate (analysing the edits, delete the helper-geometry, do next step of work)
As this approach would be most easy to implement.
To track objects between the calls you can store GUID s of the helper-object
As a helper-Object i recommend to use a block - as transforms are stored directly.
you can try to do allow nested commands - but this might create a huge amount of unwanted edits / special cases.
you can set up something by subscribing to RhinoDoc Events, for example beforeTransform
re-implement all the allowed transformations and their preview ; - ( and allow them as options of your command to be triggered. The most proper way with a huge amount of work, but precise controll of what the user is doing.
give options to your command - like Move Scale Rotate3d and those options trigger the underlaying rhino-Command with preselection. For this your command has to be a “scriptrunner”
Maybe a compromise - less work, but not full control.
But you might want to get more precise with your question and narrowed down the functionality you want. Or post some samples / current states of your commands.
kind regards -tom