Note that the larger issue is now captured in #660.

If roles A and B delegate to role C, and roles A and B have nonidentical expectations of signatures over role C, then if role C is signed by the keys B expects but not the keys that A expects, then role C may fail to be validated whether it is reached from role A or role B, even if the delegation pathways are entirely distinct in terms of the target namespaces used.

This script can be used to experiment with this phenomenon.

The quick diagnosis specific to this issue is:

updater._verify_uncompressed_metadata_file() calls tuf.sig.verify, which calls roledb.get_role_keyids(), and get_role_keyids takes only the name of a role (and a repository name), purporting to return the keys that that role should be signed by. In this case, get_role_keyids(C) cannot be expected to return the correct answer to the question "What keys should role A expect role C to be signed by?" The answers are different for roles A and B. We seek information about a delegation, not a delegated role, so get_role_keyids() doesn't make sense. See #660.