I introduced a similar call dependency and forced to call Referential Integrity Plugin before CoS.  Unfortunately, it does not update the cache with the current algorithm.

This is the steps in gdb.
Using the same test data, I removed an entry "uid=gilran,ou=people,dc=example,dc=com".
Then, refering_postop_del is called, first:
Breakpoint 2, referint_postop_del (pb=0x8242070) at referint.c:154
154             int logChanges=0;
(gdb) c
Continuing.
Next, CoS post op plugin is called:
Breakpoint 1, cos_post_op (pb=0x8242070) at cos.c:296
296             LDAPDebug( LDAP_DEBUG_TRACE, "--> cos_post_op\n",0,0,0);
(gdb) n
298             cos_cache_change_notify(pb);
(gdb) s
cos_cache_change_notify (pb=0x8242070) at cos_cache.c:3275
3275            int do_update = 0;
[...]
(gdb) n
3309            if ( optype == SLAPI_OPERATION_DELETE ||
(gdb) n
3313                    slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &e);
Now we are at the place to check if the CoS cache needs to be updated or not:
(gdb) n
3314                    if ( cos_cache_entry_is_cos_related(e)) {
(gdb) p *e
$1 = {e_sdn = {flag = 6 '\006',
    dn = 0x8331780 "uid=gilran, ou=People,dc=example,dc=com",
    ndn = 0x818ae18 "uid=gilran,ou=people,dc=example,dc=com", ndn_len = 38},
  e_uniqueid = 0x83319a0 "0bd9ba83-1dd211b2-80000000-00000000", e_dncsnset = 0x0,
  e_maxcsn = 0x0, e_attrs = 0x818a8a8, e_deleted_attrs = 0x0,
  e_virtual_attrs = 0x0, e_virtual_watermark = 0, e_virtual_lock = 0x8147a70,
  e_extension = 0x0, e_flags = 0 '\0'}
(gdb) n
3318            if ( !do_update &&
And it's concluded no need.
The issue is the update check for the CoS cache needs to be done for the referential integrity operation in addition to the main operation.  In this test case, the main operation is deleting the entry "uid=gilran, ou=People,dc=example,dc=com".  And the referential integrity operation is deleting an attribute value "uniqueMember: uid=gilran,ou=people,dc=example,dc=com" from the CoS template entry "dn: cn=uids,ou=PosixGroups,dc=example,dc=com"...