See also T169374: Add support for exception list.

Yes this solved some of the problems but not all.

If we need to check constraints on Commons (T230314), We may create another "exception" qualifier referring to Commons media, but this will not work if Meta becomes a Wikibase instance (see T173145). Of course making constraints works in arbitrary federated Wikibase instances involved much more issues, see P9457 (this is only a draft and WIP).

An additional reason is this will be more consistent with how tainted reference works, and the way external violation (against 3rd party database) will work.

Sample usecase someone mentioned on project chat not too long ago:

• father (P22) has a contemporary constraint (Q25796498) as the opposite can be an error
• Some children were born after their after father's death. A way to mark such exception this could be with a qualifier and some item, e.g. criterion used (P1013) = born after father's death (Q105083598)

Another usecase: some identifiers are sometimes reassigned. The distinct value constraint would ideally take in account start and end date. An alternative could be just use the qualifier "follows"/"followed by" to point to previous uses.

For the distinct value constraint on taxon name (P225) (mentioned above), the exception could be marked with a qualifier " different from (P1889) " pointing to the other item.

A qualifier does not solve all things: see https://www.wikidata.org/wiki/Wikidata:Property_proposal/is_exception_to_constraint.

Yes. The qualifier approach should work well for point #3 you added above: "No easy way to mark a violation as exception" when many items fail the constraints, but once in a while a value is accurate and should be marked as double-checked.

I still believe that is_exception_to_constraint in the reference section would be the best way. (I create the property proposal)

I still don't see the case against that proposal. Can someone make it here?

For me, constraints should constrain (unless they have the level of suggestion defined), and exceptions should be exceptional. Those cases where the number of exceptions ends up skyrocketing are cases where either the constraints were conceived trying to generalize too small, specific and biased a set of cases, or there's a broader underlying problem of knowledge representation that is difficult to address and users choose to add exceptions to ignore it. The first reason for this task ("Currently the way to store exceptions is not scalable") is an effect of these problems, and I think we should solve them instead of thinking of a way to add even more exceptions. The Property that motivates this task (P225) is also mentioned at Wikidata:2020_report_on_Property_constraints#Exceptions in the context of some of the problems caused by exceptions; see also T244045.

Property constraints are part of the intensional definition of each Property, and their usefulness lies in the fact that we can check their consistency with an enumerative definition, of which all uses of the Property are automatically part. A finite list of current exceptions override this automatic enumerative definition, but it does so alongside, or with reference to, the intensional definition, which applies to a generally infinite number of possible present and future entities. Ideally, the intensional definition should never refer to the enumeration or vice versa, and in the case of Wikidata it's worse because these references are not controlled: as exceptions are implemented now, I can delete a constrained statement and still have the Item listed as an exception; and, as proposed to be implemented in this task, I could delete a constraint and still have exceptions to it.

For when there are many exceptions (to a constraint that truly makes sense) I would suggest either using the suggestion level or using mechanisms other than standard Property constraints; luckily, today there are many ways to check compliance with complex rules that don't involve the Property constraint system.

In T236295#7163227, @ChristianKl wrote:

I still believe that is_exception_to_constraint in the reference section would be the best way. (I create the property proposal)

I still don't see the case against that proposal. Can someone make it here?

Maybe the exception https://www.wikidata.org/wiki/Q16645 for most constraints on https://www.wikidata.org/wiki/Property:P5086 : it could be a bunch of statements on https://www.wikidata.org/wiki/Q16645 , but it's unclear if that would really be better.

OTH, for T275392 anything that is based on the items directly seems preferable, even if it may not be theoretically appealing to non-contributors. It's still a valid constraint for these items and exceptions should be double-checked.