I'm not sure exactly what the planned role is for this system-wide thread id, but gcc and a number of other projects fall back to pthread_mach_thread_np(pthread_self()) on older systems, e.g. https://github.com/gcc-mirror/gcc/blob/58a29af8ef14bfa2d595deed5144891bff821eff/gcc/ada/adaint.c#L3305. If the role for the thread id is for identification for debugging, etc, this is probably fine, and gives good clean numbers that nslog and other tools used.. If there is some kind of thread control planned for this identifier, then that might not work out, and just declaring older systems < 10.6 as having no mechanism for uniquely identifying a thread system-wide would be likely more accurate.

@ned-deily, since you commented on the bpo issue, would you like to review this?

It LGTM but a bit too far outside my area of expertise for me to feel comfortable approving it.

Should this be closed? 10.4 / 10.5 are quite old and looking at release dates it would correspond to around 3.8 to 3.9 .

As discussed on the issue #84129, we decided not to pursue this moving forward. But thanks for the PR!