It looks like at least from the current usage of those constraint types on properties with “used as qualifier” constraints, the “sibling snaks” interpretation doesn’t make much sense: properties like “date of taxon name publication” use “item requires claim” constraints to require “taxon name”, “parent taxon” and “taxon rank” on the item.

On the other hand, I think those (along with many other “item requires claim” constraints, and also some “conflicts with” constraints) are kind of workarounds for our lack of per-type constraints: we can’t directly formulate a constraint that “all items with instance of: taxon must have a taxon name”, so instead we say that “all items with taxon rank must have a taxon name”, because the sets of items with instance of: taxon and those with taxon rank should be mostly overlapping.

This query shows all ”item requires claim” and “conflicts with” constraints on properties that also have a “used as qualifier” constraint. To me, they seem to fall into several categories:

• Constraints that look like they want to restrict the statement on which the qualifier is used – for instance, the constraint “‘elected in’ requires ‘position held’ statement” sounds like it really means “‘elected in’ should only be used as a qualifier of ‘position held’”. For this, I’m tempted to support a “property” parameter on the “used as qualifier” constraint instead.
• Per-type constraints, like “something with a ‘taxon author’ qualifier [i. e.: a taxon] should have a ‘parent taxon’”. I’m not sure these are necessary – if “taxon author” is a qualifier of “taxon name”, then surely having the same constraint (“should have ‘parent taxon’”) on “taxon name” should suffice? (Especially if we can also add a constraint that “taxon author” should only be used as qualifier of “taxon name” and no other property – see above.)
• Inverse type constraints – “conflicts with ‘instance of’ ‘Wikimedia template’ etc.”. These constraints are a bit hacky anyways, but as above I also think that having them on the parent main statement’s property should also work.

So while the interpretation of looking at other statements, not other qualifier or reference snaks, seems to be prevalent in the current constraints, I don’t think it’s actually required, and if these constraints were specified elsewhere we could still add the interpretation of looking at the other snaks instead.