Why would splitting a password output be better than separate HMACs for encryption/authentication key derivation?

In a recent question I asked here on crypto.se, an answer was given that surprised me a bit.

As mentioned in the referenced question, I'm looking to derive encryption and authentication keys from the output of scrypt. Since I can use nearly any output size I'd like in generating the output from scrypt. This leaves me two options for deriving the encryption and authentication keys:

1. HMAC the output in two different ways, ie: hmac(output, "e", sha256), hmac(output, "a", sha256); the e key is for encryption and the a key is for authentication, unsurprisingly.
2. Generate a very long output from scrypt by asking for a 512-bit output, and then split it for the key derivation for encryption and authentication.

Does any one solution fare better than the other in key derivation? I personally like the idea of using an HMAC better because then both the encryption and authentication keys use the entire key output as an input.

-
The first approach you describe is quite similar to HKDF, a KBKDF (Key-Based Key Derivation Function), whereas PBKDF2 and Scrypt are PBKDFs (Password-Based). HKDF is intended to derive key material from input that is already cryptographically random and sufficiently long. Reading this, this, and this should set your mind at ease. –  hunter May 26 '14 at 15:43

Internally scrypt has a huge state space, from which it derives 256-bit output blocks using PBKDF2-HMAC-SHA2, so it's basically already doing what you suggest as 1., just with much larger inputs. Adding another level of HMAC on top will not help.

In general, you need to be careful when chaining hash functions like $H_1(H_2(x))$. Both collisions in $H_1$ and those in $H_2$ lead to collisions in the combined hash. With a 256-bit hash you are still safe, however, since even doubling collisions gives you plenty of security margin.

If both are secure, but just using scrypt is simpler, why not use what's simple? That makes it less likely there's a mistake.

-