Indeed, the HistoricProcessInstanceQuery allows to select both running and deleted instances. As suggested by Frederik, the "end-activity" can be used as a filter, and refinement can be made on "delete reason" string.
So there is definitely a way to find out deleted instances, but as suggested, having a filtering API on the query would be the best.
Thanks for your support, and apologies for delayed feedback…
Basically, what I understood from it is that the runtime traces of the instance gets deleted keeping the historic instance for audit.
I was kind of hoping that it was a soft delete at the runtime-level as well. That way, it would be very easy to implement an undo delete method in case the process instance needs to be returned to the active pool after inspection from higher roles in the role hierarchy.
Maybe, what I am saying is not sounding BPMN compliant but there are already a lot of process instances in the rejected state which needs this feature and remodelling the workflows to have a different state like "On Hold" is not sounding like a great option because of migration issues.