Why is there no Disjoint Set (Union Find Algorithm) implemented in most mainstream programming languages' standard library?

I have found articles on how to implement a Disjoint Set (Union Find Algorithm implementation) for C++, Java, Kotlin, Python, etc.. The implementation of it is not especially difficult, although there is some room for error. It surprised me that no languages include a form of this in their standard library.

Is there a reason for this? Given how many various data structures exist in most standard libraries already, I am surprised that not one (that I have found) includes this. Is it just too obscure to include?

This is a reasonable question and perhaps there isn't really a very satisfying answer beyond "because most people don't need it". I have used disjoint set data structures perhaps 10-20 times, but pretty much only ever in the context of competitive programming; most languages' standard libraries are not designed with competitive programmers in mind. Disjoint set data structures are also needed for writing some standard algorithms like Kruskal's algorithm, but if you're implementing Kruskal's algorithm yourself then you can implement a disjoint set data structure yourself too.

Now, you might intuitively think that even if most programmers will never use it, it doesn't hurt to have it in the standard library. And it's true that it would cost very little time for the language developers to write it in the first place, but they'd also have to test it extensively, write documentation, respond to bug reports or feature requests about it, and so on. The language designers would also have to take a position on which algorithm should be the one provided in the standard library; there are various options with different performance and concurrency characteristics, so some research will be needed to choose what to implement.

On the other hand, if some niche data structure isn't in the standard library but is important enough to some programmers, then it is likely to appear in third-party libraries anyway. From the language designers' perspective, there is almost no downside in leaving it to third-party library developers.