There are two answers: the "engineering" answer, and the "principled" answer.
The engineering answer is that, in practice, if you generate two keys using two different info strings, I suspect you'd probably get away with it without problems. If we model the hash as a random oracle (admittedly a very strong "assumption"), then I suspect it might be possible to demonstrate that what you propose is OK. Disclaimers: I haven't analyzed this, and I'm certainly not going to give you any guarantees -- if you do what you propose, cryptographers will wag their finger and say "tsk, tsk", and rightly so. I suspect you'd probably get away with it (it's not the worst sin you could make), but if something does go wrong, cryptographers aren't going to take the blame -- it's all on you.
The more principled answer is that if you do what you propose, you are misusing the HKDF primitive. The HKDF is only intended to be applied to a single $Z$ once. It is intended to turn an unguessable value into something that looks uniformly random. It has been analyzed for that use. It was not designed to derive multiple keys from the same $Z$: it hasn't been analyzed for that kind of use case, since that's not what it was designed for. So, you're throwing away the benefits you could get from the public analysis of HKDF if you use it in a way that it wasn't designed for.
Consequently, given that it is so easy to apply a PRG or PRF to the output of HKDF (using HKDF to get a uniform-random key, and using a PRG or PRF for key separation, i.e., to derive two different keys), you should probably do that, instead of what you proposed. Given that it is so easy to do the principled things, you might as well do the principled thing, and use the HKDF only once on any given $Z$. Even though you could probably get away with cutting corners and doing what you proposed, I see no reason to take the risk (even if the risk is miniscule).
So, stick to using HKDF in the way that its specification tells you to. Don't cut corners. In this case, there's not really any compelling reason to deviate from standard cryptographic practice, so you might as well stick with what the specification and cryptographers recommend.