Nick Petit

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.

With Next Constraints, the constraints have next_constraint_name and next_constraint_type attributes which causes the constraints to, when broken, switch to this constraint name and type instead of being deleted.
next_constraint_name then becomes constraint_name and next_constraint_type becomes constraint_type.
Keep in mind these are the only 2 next_* attributes that get renamed this way.

Having the next_constraint_name be the same as the constraint_name isn't all that useful since they share the same attributes. For example, if both constraint_name and next_constraint_name are set to "Glue", since the constraints will have the same "strength" value (there is no next_strength attribute) when the constraint breaks due to an impact being stronger than the constraint's strength, the constraint is broken, switches over to the next_constraint (Glue in this case) and immediately breaks again since the impact is stronger than the constraint's strength.

If you want to change the constraints' strength over time, the simplest thing to do is to animate it in SOPs with a RBD Constraint Properties SOP node and add the "strength" attribute to the RBD Bullet Solver SOP's list of constraint attributes to override. On the RBD Bullet SOP, under the Constraints tab, Override Attributes, enable the Attributes and add "Strength" there.

Here's a hipfile with various examples.

If you have a hipfile it'll help identify what's going wrong. The way the sim is behaving looks very wrong - I suspect it might have something to do with you possibly having duplicate names in the RBD pieces and constraint anchor names since you are fracturing in a for loop.

Here's a simple example showing the distance threshold breaking the soft constraints.