Yes, it raise a flag for me that that -4 could become -3 if the original -3 is deleted.
A better approach may be a hybrid of the two previous suggestions.
- Create a Child field to store a static sibling number
- (Just plain numeric field. But in the field properties, check the box to Treat blank values as "0" in calculations.)
- Create a summary field on the Parent that finds the max sibling number (of field the above)
- (This is different from a Child count. Use max instead.)
- Create a Pipeline that is triggered when a Parent is created
- The Pipeline will set the Related Parent on the child
- The Pipeline will set the static sibling count based on the Max summary and then add one via Jinja.
- e.g. {{a.sibling_count + 1}}
You should be fine displaying the Child record info that way, but I would suggest leaving the Child's default "auto-incrementing table key" alone. In other words, be careful of any relationships based on the "-x" suffix.
The main point being use max vs. count on the Parent summary! Then, that could be set permanently on the new Children. And be careful when a Child is deleted, as you could still run into the -x shifting when the most current child is deleted. e.g. If you have four children and -4 is removed, but then a new Child is added it would become -4.
Ahh, writing the above, I realized yet another alternative. Store the sibling count on the parent. And just increment it whenever a Child record is created. That way you shouldn't end up with using the same sibling count twice! For example, in the Parent's button to Add Child you could increment the parent count, then add the Child (so the same button would edit and add record via nested redirects). Or perhaps a second Pipeline could be create that increments the Parent whenever a Child is created. I suppose it depends on how you intend to create Children!
Anyway, there are multiple ways to approach this. Hopefully that gives you some ideas without too much confusion!