To expand on Peter's comment, ISOGG has never been an arbiter of SNP identification. SNPs weren't reported to ISOGG; their haplotree was maintained manually by a very few volunteers, notably Ray Banks, by accessing and reviewing the publicly available data from FTDNA and others.
We had a conversation about the status of the ISOGG haplotree last December in the private ISOGG group following questions that arose on Anthrogenica. The ISOGG haplotree isn't officially retired, at least not yet. It's really the only repository that continued using the YCC's long-form nomenclature, so if it's retired I don't expect that the last version, v15.73, will be taken down, but will remain for reference. When a decision is made, I fully expect a statement to be published both on the ISOGG tree main page and on the ISOGG Wiki.
But we have an even more troubling conundrum with Y-SNPs. Since the demise of the YCC there has been no governing body to take control of vetting and curation of named Y-SNPs. One result is that we now have two dominant haplotrees, one at FTDNA and one at YFull, and they are different. Particularly under the R clade, as we get deeper there are differences of opinion about bifurcation and identifying SNPs. A third tree is at YDNA-Warehouse, ydna-warehouse.org/tree. I've had both my Big Y BAM and that of a WGS analyzed by YFull and YDNA-Warehouse, and I have slightly different haplotree structures and terminal SNPs reported at FTDNA, YFull, and YDNA-Warehouse. It isn't terribly difficult to sort them out...but it would no doubt be bafflingly confusing to someone new to yDNA for genetic genealogy.
Another problem that we've brought about is that we've used the term "SNP" more loosely than the academic/research community. By definition, a SNP is something that can be found in at least 1% of the global population. A predominance of what we see as recently-appearing haplotree sub-branches are not SNPs at all; they're SNVs, Single Nucleotide Variants. They haven't been found in large enough proportions of the population to be SNPs, and the deeper we go in the haplotree the less likely it is that they will ever be.
That doesn't lessen their value for population genetics or genealogy, of course. It's just that we use the term incorrectly.
The other repercussion of having no governing body managing identification and naming is that we're seldom actually discovering truly new yDNA SNPs/SNVs. Independent researchers (and that includes FTDNA, YFull, and YDNA-Warehouse) are, basically, finding more than one consistent, correlated variant whose locus they don't see as having been given a name (at least, the kind of names we're familiar with), so they name it. The numbering sequence is only internally consistent within their own naming prefix (e.g., FGC for Full Genomes Corporation; BY, BZ, FT for FTDNA; Y for YFull). That's how we end up with synonymous names that identify the same locus and same polymorphism.
Something that is curated is the dbSNP database, maintained by the National Institutes of Health. I haven't pulled recent data for the FTDNA haplotree, but as of December 2021 they note that they have over 460,000 variants named in their haplotree; it's probably well over a half-million by now. At dbSNP, there are currently almost 2.7 million SNVs and SNPs cataloged for the Y chromosome. That's what I meant when I said that, for the most part, we aren't discovering new polymorphisms, but rather categorizing them in haplotrees based on ancestral/derived relationships.
Every entry at dbSNP is assigned an rsID. Standing for "reference SNP cluster ID," if you've looked at the raw data from an autosomal microarray test you've seen tons of them because that naming convention extends across the genome. However, the valuable aspect of constant curation is the very reason we can't really use rsIDs for naming yDNA variants. The NIH is receiving newly reported data about polymorphisms all the time. When a new one comes in, the vetting is minimal and an rsID is assigned. Then they go back and do a deeper investigation. If the same locus and same polymorphism has been referenced by a new report, the data is reconciled and the new rsID is merged back into the earliest rsID representing that particular variant.
In the long run, that's the way to go...it's the same approach WikiTree takes with duplicate profiles. But it could play havoc with haplotrees. It would mean the haplotree publisher wouldn't be in control of their own tree. If they had established, for example, "rsID987654" as the defining SNV/SNP for a parent branch with a few bifurcations beneath it, and months later dbSNP determines that should be folded under previously cataloged "rsID123456," then the tree would need to change dynamically and our reported position on the tree and terminal SNPs would stay less stable than they are now.
This is all far afield of Greg's initial question, but I thought it worth level-setting the information about ISOGG and some of the challenges we face with yDNA haplotree structures...not just trying to deal with it here at WikiTree, but in general.