TL;DR No one can predict the future (so theoretically the case you present can happen, in practice I wouldn't bet on it), especially because ICANN, in charge of TLDs creation has a lot of rules and procedures, that change over time, with decisions that can later be appealed, reversed, upheld, and redone. So expect the unexpected.
Now, in more details (the whole subject is fascinating if you dig it)
ICANN world and rules
What are the criteria used to allow these new domain name extensions and who is regulating this ?
ICANN is regulating this, as with all gTLDs. All the names you list are from the 2012 gTLD round. You can learn more about it at https://newgtlds.icann.org/en/about/program
They were rules on what strings can be requested, and even some rules about potential confusion. The bible is the applicant guidebook, which is almost but not completely all the rules: https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf with 338 pages
For your specific question, you should find "String Contention Procedures" at https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf (28 pages) most relevant.
String contention occurs when either: [..]
Two or more applicants for similar gTLD strings successfully complete
all previous stages of the evaluation and dispute resolution
processes, and the similarity of the strings is identified as creating
a probability of user confusion if more than one of the strings is
The String Similarity Panel will also review the entire pool of
applied-for strings to determine whether the strings proposed in any
two or more applications are so similar that they would create a
probability of user confusion if allowed to coexist in the DNS. The
panel will make such a determination for each pair of applied-for gTLD
strings. The outcome of the String Similarity review described in
Module 2 is the identification of contention sets among applications
that have direct or indirect contention relationships with one
"Module 2" is in fact https://newgtlds.icann.org/en/applicants/agb/evaluation-procedures-04jun12-en.pdf (43 pages) that deals with multiple points, but about String Similarity Review, it says this:
18.104.22.168.2 Review Methodology The String Similarity Panel is informed in part by an algorithmic score for the visual similarity between each
applied-for string and each of other existing and applied-for TLDs and
reserved names. The score will provide one objective measure for
consideration by the panel, as part of the process of identifying
strings likely to result in user confusion. In general, applicants
should expect that a higher visual similarity score suggests a higher
probability that the application will not pass the String Similarity
review. However, it should be noted that the score is only indicative
and that the final determination of similarity is entirely up to the
The algorithm was hosted at http://icann.sword-group.com/algorithm/ but this does not resolve any more today (someone at ICANN forgot to read and apply "Cool URIs don't change"). You can find latest snapshot by the Web Archive at https://web.archive.org/web/20131027203439/https://icann.sword-group.com/algorithm/ but of course then the form does not exist so you can not try the algorithm.
Because out of all procedures, and after 8 months, the "Panel" determined that only 2 sets of different names existed as confusingly similar:
You can also find details about all "contention sets" that were considered at
You will see there only considered in fact multiple applications for the exact same string.
There are other cases on which one could be surprised, for example
cars (all those 4 exist today). You can as well consider
properties (those all 4 also exist today).
In short, some tool computed a percentage as similarity but then a panel decided what to take into account or not. And it didn't take a lot into account and then all the objection process at ICANN was so complicated that not a lot of people complained anyway, except the users probably.
This article (http://domainincite.com/11997-after-eight-months-similarity-review-creates-only-two-new-gtld-contention-sets) right after the first decisions says:
For example, we now know that plurals are fair game: if Donuts’
application for .dentist is approved in this round, there’s nothing
stopping somebody else applying for .dentists in a future application
Of course this plural thing was discussed extensively at next ICANN meetings and you can read
for a detailed discussion.
Note in particular what is says about the strange results of the panel based on what the algorithmic tool could have said otherwise as similarity:
To date, nobody except the Panel and ICANN knows what the logic behind
this decision was, but it appears to be based on a very narrow (though
not unreasonable) interpretation of what constitutes visual
Note that it is "planned" for new round of TLD candidates to open. No one knows when nor exactly the rules that will then be used, and hence if the cases you describe could happen or not. So theoretically anything is possible at this stage, yet for the 3 example you use (
orgs), I am pretty sure that the current registries of
org would make their voice heard loudly about something they will surely consider as VERY similar and hence confusing.
Everything is so similar everywhere...
Also, string similarity problems are not limited to this new gTLD round. In the past, ICANN refused for a long time to let
.бг exist (Bulgarian ccTLD written in Bulgarian) citing confusion with possible existing
.br (for Brazil), and
.ελ for Greece in Hellenic, because too close to
.ea (which does not exist as ccTLD in fact). Things changed, but it was slow.
The problem is even larger if you take into account semantics: are
photography (4 existing gTLDs), "confusingly" similar because semantically kind of synonyms?
.shopping were considered too confusingly similar for example, see http://domainincite.com/14738-shopping-ruled-confusingly-similar-to-shop or at http://domainincite.com/14239-string-confusion-in-disarray-as-demands-cam-loses-against-verisigns-com for
cam that was refused because too "close" to
com (but in fact later
cam was allowed).