[tmtvl]

Yes, that post was mentioned in the article I linked:

Even Emacs current threads library suffers from data races which is one of the reason I believe it has not seen much adoption.

(where suffers from data races is a link to Chris Wellons' post).

The idea now is, as Chris states:

There really needs to be a safe, high-level API with clean thread isolation. Perhaps this higher-level API will eventually build on top of the low-level threading API.

While you are right that for 99% of standard usage single-threaded code is entirely fine, not utilizing between half to 15/16ths of potential processing power is a bit of a shame, especially considering it means doing something like indexing an entire project (yes, we can use GNU Global) will require the user to just sit and wait.

[medstrom]

That "99% of standard usage" is the kicker, isn't it? The greybeards who opposed multithreading since the beginning tend to say that the remaining 1% of use cases is best done in an external process, ideally not even written in Emacs Lisp, so that Vimmers and the rest of the free software community can benefit. The GNU Global you mention embodies that ideal exactly.

I suppose if you still want that program to be written with Emacs Lisp, you could use async.el (https://github.com/jwiegley/emacs-async/) and there's finally an use-case for the threads: it'll be relatively safe to run those 16 threads only in the external Emacs-process.