See the original project in the attachment.
I have an entity B, which owns an entity A in a 1-to-1 relationship. A may exist without B, but not vice-versa. Besides, multiple instances of C may be associated with B, though instances of C may also exist without being related to B. I have marked B with CascadeType.All and enabled orphan removal in A, C is marked with CascadeType.All end orphan removal enabled on B as follows:

class A {
ID id;

@OneToOne ( mappedBy = "A", orphanRemoval=true, cascade = CascadeType.ALL)
B b; }

class B {
ID id;

@NotNull
@OneToOne (optional = false)
@JoinColumn(name = "a_id", nullable = false, referencedColumnName = "id" updatable = true, unique = true)
A a;

@OneToMany ( fetch = FetchType.EAGER, cascade = CascadeType.ALL, orphanRemoval = true)
@JoinTable(name="B_to_C", joinColumns = @JoinColumn(name="B_id", referencedColumnName = "id"), inverseJoinColumns = @JoinColumn(name="C_id", referencedColumnName="id"))
Set<C> listOfCs;}

Following will now fail:

A a = new A();
B b = new B();
b.setCList(getABunchOfTransientCsByMagic());
a.setB(b);
b.setA(a);
a = aRepository.save(A);
a.setB(null);
aRepository.save(a);

The last statement will fail for hurting the fk constraint lying on b_id in the b_to_c join table. The reason for this is, that Hibernate is putting the delete actions (deletion of B, B_to_C and C) in the wrong order. Debugging showed, that in the session's action queue B is deleted first, then the entries in B_to_C and finally the C instances. The funny thing about this is, that if A is owning B, everything just works fine (B_to_C table is deleted before B is accessed).