XorShift and Xoroshiro are LFSRs. LFSRs are a component of some hardware-implementation-focused algorithms. LFSRs are not secure on their own. They are linear, so their state (and thus future output) can be predicted from a few known output bits. Additional operations have to be used in stream ciphers that utilize LFSRs.
Mersenne twister is based on a generalized feedback shift register, so it has similar properties. (Note that generalized does not mean better. Algorithms recommended by Sebastiano Vigna are faster, smaller, and have better quality ouput.)
The operations that CryptMT adds on top of Mersenne Twister will not necessarily (and probably won't) work well with different base RNGs. So Do Not attempt to make your own Frankenstein algorithm.
We shouldn't even be confident that CryptMT is secure. It hasn't received much scrutiny compared to other algorithms. Its design is unusual. (It looks ad hoc and brittle to me. Like RC4.)
The reason why it was rejected in favor of other ciphers is because "The security of the cipher, in particular the non-linear filter component, might not yet be as well-understood as some of the other finalists."
Most non-secure RNGs are quite different from secure ones. Non-secure RNGs, at best, perform just enough scrambling to make patterns in the sequence harder to notice. Secure RNGs must have no exploitable bias or patterns, cannot permit an attacker from using known output to predict past/present output bits they haven't already seen, and can't be vulnerable to key/seed recovery.
It's not easy to build a better secure RNG from an insecure one. Any method based solely on filtering is questionable. You could tweak the original RNG until it's secure, but that would be a totally different algorithm. Or you can pass output through a PRF as is done in CTR mode. But you can use any non-repeating sequence with the PRF, including cheaper ones like incrementing a counter.
Instead of CryptMT, I suggest using ChaCha. Most people, unless they have a good reason to use another specific algorithm, should choose ChaCha for the software they write. ChaCha is fast, secure, and makes efficient use of modern computer hardware.
(If you must use lightweight algorithms on an embedded system, then the answer depends on several factors.)
At the same time it has to be unpredictable enough so the attacker has little control what matrices are generated when messing with the seed.
That may rule out some algorithms. The security of cryptographic algorithms is usually predicated on the key being randomly chosen. (Related key attacks and weak key classes exist with some algorithms.) For RNGs specifically, it may be possible for an attacker to decide on a desirable RNG state and run the initialization procedure backwards to find a seed which leads to that state.
There isn't such a problem with ChaCha used as an RNG. If you don't need secrecy from the algorithm, you can freely choose the key, IV, and counter value. (Ideally, use a secret key and limit the variables the attacker controls to the IV.)
Because each output block from ChaCha is generated using a (really good) one way function, it isn't possible to search for desirable seeds with any method faster than brute force. Certain hash-based RNGs wouldn't have that problem either.
ChaCha adapted from a stream cipher to an RNG should be your First choice for secure deterministic RNGs. (But it Does Not provide backtracking resistance, so consider erasing or replacing the key after some time.)
Alternatively, Blake2X, Skein, and KMAC can be adapted for your Second choice. They all accept secret keys and are all extendable output functions, so it's possible to output as many pseudorandom bits as you want.