BUT since there is no ability to change the active-context through the API then paste-in-place is pointless...
If you Cut or Copy then Paste with send_action it's sine because the original selected object and the newly copied/cut then-pasted one are in the same context, and the user gets the copy on their cursor to place manually.
But let's assume there were a seemingly usable Paste_In_Place send_action available through the API, how would it be of any use ?
Say you are in the the model and want to Cut an object, open a Group and then do a Paste_In_Place on the object inside the Group.
In the API you can Cut it.
BUT you are now stuck as you can't open the Groups context.
Paste_In_Paste will simple place the object back where it was, in the current context !!!
There IS a way to replicate all of this 'in code'... BUT your Ruby_Cut and Ruby_Paste_In_Place into another 'container' custom code needs to make a group of the selected objects, then find that group's definition and then use container.entities.add_instance(defn, trans) on the other container's entities context, applying the container's transformation onto it [with a .inverse ? I write this 'off-the-cuff'], so that it's kept 'in_place'. Once that is done you explode that newly added group inside the container, then finally you erase the original group so the selection appears to have been cut and pasted_in_place into the other container... If you mimic a Ruby_Copy and Ruby_Paste_In_Place it's similar... except on completion you also explode the original group rather than erasing it, and in that way the selection appears to have been copied and pasted_in_place into the other container...
