The Mersenne Twister (MT) was one of the best engines and was the default in many other languages/packages too. See "Applications" section in wikipedia - https://en.wikipedia.org/wiki/Mersenne_Twister
The author identified distribution problems with the 32-bit versions of MT (i am not sure whether similar problems exist with its 64-bit versions) and proposed a different one named "Permuted Congruential Generator (PCG)" which has now been adopted as the default by many of the languages/packages - https://en.wikipedia.org/wiki/Permuted_congruential_generato...
As you can now appreciate, the subject is mathematically complicated and the defaults chosen by the language/package implementer becomes the "most commonly used" and hence reference case. While this is good enough for most "normal" applications if you are doing any special simulations (Monte Carlo or otherwise) and/or specific Numerical Computations it is your responsibility to understand what it is that you need and program accordingly using the various options (if available) or roll your own.
> (i am not sure whether similar problems exist with its 64-bit versions) and proposed a different one named "Permuted Congruential Generator (PCG)"
The 64-bit version might be a bit faster (for certain workloads, on 64-bit hardware) than the 32-bit version, but still wastes the same space and has the same mathematical flaws.
PCG is still not perfect (128-bit math hurts, though the new DXSM variant at least reduces that to 128x64), but its mathematical properties are nicer than the xor* family (its main competitor), and both families are miles ahead of any other RNG out there.
It is understanding the non-trivial statistical properties (even at a simple conceptual level) that is of paramount importance. PRNG is one of the most difficult subjects in Numerical Computation and has nothing whatever to do with any language/package/library etc.
Even today, caution is sometimes required, as illustrated by the following warning in the International Encyclopedia of Statistical Science (2010).
The list of widely used generators that should be discarded is much longer [than the list of good generators]. Do not trust blindly the software vendors. Check the default RNG of your favorite software and be ready to replace it if needed. This last recommendation has been made over and over again over the past 40 years. Perhaps amazingly, it remains as relevant today as it was 40 years ago.
It was better than the bad, C interface LCG rand(), I guess. (There are LCG parameters that make for ~objectively better PRNGs than MT, but rand()'s parameters aren't great and its state is too small.)
I've found it easier to write my own PRNG than to use the std. Using the std PRNG is about as buggy as my implementation, so the trade-off is reasonable. I usually need non-cryptographically strong PRNGs, so xorshift128+ is sufficient.
I used it because it was recommended by Stephan T. Lavavej, maintainer of Visual Studio's C++ Standard Library, in his "rand() Considered Harmful" talk, back when <random> was introduced. See 11m30s. https://youtu.be/LDPMpc-ENqY?t=10m50s
There's std::linear_congruential_engine, but it doesn't provide you with any (good) default parameters; only the bad ones from historical rand() implementations (minstd_rand0 / minstd_rand).