This opens a lot of use cases and is perhaps required for proper infobox support in Wikipedias. Often the label in the left column isn't exactly the one which is assigned to the property on Wikidata. Allowing to find properties by aliases would solve this issue in most cases and aliases being unique is a requirement for this.

Btw I've created a SPARQL query to find aliases which are used more than once. https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples#Aliases_of_properties_which_are_used_more_than_once

Beware potential performance issues when checking for uniqueness wrt queries to the wb_terms table.

Adding Sjoerd and Andy for information. This will mean a few properties will have to have aliases removed. But if we want to make it possible to use not only labels but also aliases in the property parser function then we'll have to do this.

Thank you for the notification. Having looked at the examples produced by the query shown above, I am concerned that removing some my impact usability for people editing or adding to Wikidata manually.

At the very least, we will need to think about suffixing new aliases, so that typing the current stings (e.g. instead of using "child of", twice, we should create "child of (father)"/child of (mother)")

As written above, this query lists all aliases which are used more than once (english only, replace "en" by any other language code to check those languages as well): http://tinyurl.com/nf9uyks

Edit conflict as I modified my last comment; sorry Bene ;-)

In T89661#1337217, @Pigsonthewing wrote:

At the very least, we will need to think about suffixing new aliases, so that typing the current stings (e.g. instead of using "child of", twice, we should create "child of (father)"/child of (mother)")

That sounds like a great idea. I really like that.

Furthermore, we have to make sure that no conflicts exist when this change reaches production so that there won't be any uneditable properties like there were after the last constraint change.