Dancing confusion with Daniel J. Bernstein's stream ciphers
XSalsa20 uses the same cryptographic core as Salsa20 and comes with a security proof that it's secure if Salsa20 is secure. It doesn't use the core of ChaCha and thus has worse diffusion.

The way XSalsa20 works is that it hashes its 256 bit key and the first 128 bits of the nonce using HSalsa down to a 256 bit key and then uses that key together with the remaining 64 bits of the nonce in Salsa20. You can find the details in the paper Extending the Salsa20 nonce.

The problem with nonces is that you must be sure that you never reuse one. With a 64 bit nonce a counter works well, but a counter is stateful. If you want a stateless nonce, the usual approach is to generate a random one, and assume that collisions are sufficiently unlikely to happen. Assuming uniqueness with a random 128 bit value is pretty safe, but with a random 64 bit value collisions become likely even with a moderate number of messages. So you can't use random 64 bit nonces. But if you have a 192 bit nonce, you can randomize it.

Thus the increased nonce size isn't a security improvement, but a feature that allows random nonces.

In principle it's possible to use the same nonce extension technique with ChaCha, but Bernstein didn't publish a specification. In my answer to Can I use the ChaCha core as a 256-bit to 256-bit one-way function? I describe how to construct HChaCha from ChaCha, in the same way HSalsa20 was built from Salsa20. Combining HChaCha and ChaCha into XChaCha is straightforward.