Maybe the best solution would be adding a parameter to the constraint allowing the user to specify if, for that specific property, "mul" should be taken into account or not. This would be the most flexible solution IMHO.

To avoid complexity in the implementation a blanket rule would be ideal here. Are there any cases in which mul would not be accepted as a value for the "Label in Language" property constraint?

If we are going to prevent labels that are the same as mul from being entered, then mul must be accepted all the time.

I agree @Midleading, and this is the primary function of mul

In T370293#9990985, @Epidosis wrote:

Maybe the best solution would be adding a parameter to the constraint allowing the user to specify if, for that specific property, "mul" should be taken into account or not. This would be the most flexible solution IMHO.

You can already do that by adding a second qualifier with mul as the value, e.g. https://www.wikidata.org/wiki/Property:P6655#P6655$ABA93DD0-4E13-4633-AAA7-E21E2D16726B removed the constraint violations related to the label on https://www.wikidata.org/wiki/Q3863922#P6655.

Change #1063173 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Always accept mul label in LabelInLanguageChecker

https://gerrit.wikimedia.org/r/1063173

Change #1063174 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Add strict types to touched files

https://gerrit.wikimedia.org/r/1063174

Note that, once the above changes are merged and deployed, cached constraint check results with violations for missing labels can still be shown for up to one day ($wgWBQualityConstraintsCacheCheckConstraintsTTLSeconds, 86400 seconds = 1 day).

If another qualifier is used to specify whether "mul" is always accepted, then the number of qualifiers already equal to adding "mul" as a second accepted language as proposed above as a workaround.
Because it's not clear how this extra parameter is defined, and whether this extra parameter would be too complex to implement, I think it's better to discuss how the more flexible parameter should be added as the next feature to support. Better not to block "mul" deployment due to this (There are other more serious issues to fix in "mul" language code than this one).
And many times languages with non-Latin alphabets still use a Latin label, such as "MediaWiki" and "PHP". These labels shouldn't be added to a specific language merely because a property constraint opt-out of accepting "mul" label.

I think we should move ahead. I am concerned that if we don't implement it users may re-add all the labels that were removed because of mul, and create issues going back and forth with violations and removing and re-adding labels.

Change #1063173 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Always accept mul label in LabelInLanguageChecker

https://gerrit.wikimedia.org/r/1063173

Change #1063174 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Add strict types to touched files

https://gerrit.wikimedia.org/r/1063174