Is there a way to protect referential integrity between two related entities?

Have you tried the access control to the delete route? You could simply prevent the delete button from being displayed in the UI if you don't allow access to that route if that entity has entity references assigned to it.

Thanks for the quick response. I have thought about removing the delete button from the UI. But this would not work if you, for instance, bulk delete entities (like via VBO).

Well, it's not about removing the delete button, it's about removing the permission to delete a specific entity. If that permission is gone, then all tools that properly follow APIs should not present the delete option (either button or item in a list) if the current user doesn't have the permission to use it.

For batch processes like VBO, that a bit more tricky, as some selected items may be allowed to be deleted, others are not. In that case, VBO should check the permission during processing and not delete those where the user doesn't have permission to do so.

Could you please elaborate on the "access control to the delete route" topic that you mentioned?

I have looked into this example (and this video), but I'm still stuck. The ECA Access result action that this method presents only works with the ECA endpoint access event that cannot - I suppose - be used here due to its parameter restrictions (/eca/...).

The delete route to which access should be denied to would have the format /node/[node:nid]/delete. (For the sake of simplicity, I disregard the bulk delete variant mentioned above).

What I have achieved thus far is using the Build form event, with a condition, and the Form field: Set access action (Set as access: no) and displaying an Error msg at the end.

This hides the delete option effectively, but the usual "This action cannot be undone" system message is still shown.
Is there a better solution, another event - action that would react to the /node/[node:nid]/delete route, for example?

Your can use the Determining entity access event and use that for your entity type node with the operation delete. Following that event you can do all your conditions and then use the Set access result action to either allow or deny access.

This event will be used whenever e.g. a link gets created, and if the current user doesn't have permission, the link will not be provided.

Thank you! This, indeed gives the access denied page on requesting the delete operation. I did experiment with this event-action chain before, and I see now the reason why (I thought) it did not work. It leads to the expected results only if user running the eca rule is not of ID 1 (administrator). And I tested the model earlier with my ID 1 account.

I consider this issue closed. Your help is much appreciated!

Haha, yes I ran into that user 1 problem myself before as well. We've banned that global user 1 feature completely, as it causes more issues than it actually solves.

Thanks for your feedback, glad it solved your issue.