Refer to curator guide and the last comments of this flag for discussion on how to deal with complexes.
The current problem with complexes now is that the name has to be the type species; example being Gray Tree Frog in which the scientific name is the type specimens. Confusion with this method might be, because two taxa are named the same, how many observers are going to mistakenly submit to the wrong taxa. One of the solutions offered is to ensure the complex has an English name clarify it’s a complex but I wonder if the following is better.
Many taxonomists have often used brackets or parentheses to describe superspecies. For example, someone who believes the Horned Lark is one of many species may call the European populations Eremophila [alpestris] penicillata or a person who believes the McKay’s Bunting is not a real species may call it Plectrophenax [nivalis] hyperboreus. eBird often uses brackets to summarize field-identifiable subspecies groups like the Oregon Junco Junco hyemalis [oregonus] to indicate the person is referring to the 6 subspecies instead of the type subspecies.
Insect taxonomists use parentheses to describe species with subgenera as their parent. Orthoptera Species Files (OSF) refers to a cricket species as Gryllus (Homaloblemmus) zambesi to indicate that though it’s a part of the subgenera Homaloblemmus, its scientific name is still Gryllus. They also refer to species groups in this manner, such as Melanoplus (sangunipies). I think implementing this into complexes will help keep them erroneous identifications but I’d curious as to opinions to this.
I don’t think I’ve ever seen brackets or parentheses used in the nomenclature for species complexes themselves (in the strict sense) and I think it would make things more confusing to implement them such that it’s an iNat-exclusive system. The correct notation I believe is “Type species-complex” which I think would aid in mitigating confusion if iNat adopted it (not “Complex Type species”). However, staff have said before that changing the naming system for each taxon rank would unfortunately be quite a big undertaking given the current system being used.
This is a point of discussion with the eventual introduction of genus- and species-groups as well as you mentioned. Instead of “Taxon-group” it will be “Species/genus Group Taxon” based on the current system. This is an issue that will definitely need to be addressed once things get moving, I think.
The issue with subgenera really irks me hahah—calling subgenera “subgenus _____” without mentioning the parent genus in the taxon name makes things confusing when there are multiple subgenera with the same name in different groups (same will apply to species groups). Staff have said that implanting the system of “Genus (Subgenus)” would be a pretty major change to the current way things are run and isn’t a priority at the moment, so we’ll have to see what comes of it.
In this case, it seems like it would make much more sense to call it Grey/Cope’s Treefrog Complex (Hyla versicolor/chryoscelis) This wouldn’t work for all complexes, but when only two species are included this should remove any chance of confusion.
I mean, technically it’s “wrong” by curator guide but if the complex contains and only contains two species, where’s the harm in adding the slash. eBird does this with slashes like Western Flycatcher and Sharp-shinned/Cooper’s. However if it’s three or more, it’s by “sp.” or “complex”.
I think it would be awesome if more than one identification could be suggested for an observation, where a user could ID something as ___ or ___, even if there was no complex. In those cases, the community ID would be the highest shared taxon, but wouldn’t restrict future more-specific ID’s if the possibility arose. But these observations would still be marked to a page of some sort—maybe not in the taxonomy tree but somewhere in a revamped/additional tab for ‘species’ observations that included more options (like identifications of the genus alone even if species-ID’s are present). It’s hard to dictate what I mean, but BugGuide has a bit of an equivalent where we do this: https://bugguide.net/node/view/5256/bgpage?from=21
probably getting too complicated at that point though :P