As I said, I’d want to use the functionality of the std::thread implementation and everything that comes with it alongside the Juce implementation, and I’m not convinced that mixing that would play out nicely.
Addition to clarify:
As the Juce Audio and Midi systems already use Juce Threads, I cannot for my use case switch to only standard library threads without breaking Juce (which I wouldn’t want to do, maintaining a personal fork is a PITA).
However, I especially need promises and futures, which are rather hard to create by foot, and most certainly would not meet the quality of testing, robustness and performance as the standard library implementation (which is basically the old boost::thread).
Thus, having an optional (read: brought in by setting a flag at compile time) implementation of Juce threads on top of std::thread, with exposure to sth std::thread interface shall it be used and so desired, would very much be beneficial.