RFC: asymmetric "For Coverage" semantics

I have been discussing the issues with the current semantics of the "For Coverage" checkbox in the Support forum with @Geoffrey Clemm and would like to make a formal proposal here. The most relevant prior discussion I found here was a couple of 2016 threads, back when I'm not sure the checkbox even existed:

• One-Way Relationship Requirements
• Relationship coverage should accommodate unidirectional relationships

Thus I'm creating a new thread.

Current Situation

The default relationship rules for the Medical Device Framework create a number of "fan-in" relationships to item types:
In particular, System Requirement, Subsystem Requirement, Verification and Validation.
The current semantics of marking a relationship For Coverage (beyond making the line solid in the above diagram) is to flag every instance of either end's item type if it lacks such a relationship. I call these semantics symmetric.

My belief is that this semantic is only valuable for the upstream item type:

• Every User Need must have a Validation, but some Validations are for Risk Evaluations, and do not link to a User Need.
• Every Requirement must have a Verification, but a given Verification is for either a System or a Subsystem Requirement, never both.

The symmetric semantics of the current feature greatly impede its value for the typical RRD, which has fan-in relationships. Geoffrey advised me to give up on the feature and use Filters and Reports (with separate "exception-flagging" attributes) as a workaround.

I would rather propose the following refinement to For Coverage semantics, which I believe will make the feature more useful:

Proposal: asymmetric For Coverage semantics

Every instance of an item type must have:

• At least one instance of every For Coverage relationship where it is the upstream type
• At least one instance of at least one For Coverage relationship where it is the downstream type

Otherwise, the instance's relationships are flagged as missing (with today's UI, although see my related proposal).

Thanks for your attentive review.