Nick Petit

The RBD Bullet Solver SOP stores all the emitted geometry in a solver SOP, at its emission position, rotation and scale. From there it's a straight forward transform pieces SOP.
The reason it does this is there is no guarantee that all the unique emitted geometry is always available through the first and/or third inputs.
For example, on frame 1 you have a cube plugged into the first frame - a cube is emitted. On frame 2 you switch to no geometry, so nothing gets emitted and on frame 3 you switch to a sphere which gets emitted. On frame 4 and up you switch to no geo.
Without caching the emitted geo, you'd only see the cube on the first frame and the sphere on the 3rd frame and then nothing.

Storing the emitted geo at its emission position, rotation and scale is the same as baking in its rest xform.

Here's one way of detecting impacts inside a SOP solver inside the RBD Bullet Solver SOP.

I don't think that file is the same as the one you showed the problems with, I can't repro the issue in this file and the ball position is very different to the one in your video.
I did notice that you are fracturing the pieces in a for loop, which will result in duplicate names for different pieces - if you use a connectivity SOP to create the name attribute before the RBD Material Fracture SOP, enable the "Fracture per Piece" option, you'll get the same result without the need for a for loop.

You use 2 assemble SOPs to create the names with the same prefix then merge - this results in overlapping names.
In /obj/constraint_and_sim_test you unpack the packed fragments and pipe that through a connect adjacent pieces SOP to create the constraints (which have duplicate names). You then repack the unpacked geo with an assemble SOP set to create the names which creates new unique names - your constraints won't match up with the geo.

Here's a cleaned up version of your hip file with no overlapping names.