When updating the zig test runner to use version 2 of the test runner interface, we will need to parse the test output.
We could use bash and jq, as used by bash, awk, jq and various other tracks.
Or we could we use a zig program, like how the cpp and nim tracks use their respective languages.
Is there a preference?
I think it’s nice when language tracks build tooling in their own languages … but reusing existing jq code from all the other test runners allows code reuse and consistency. So opinions both ways and no preference from me 
As a guardian familiar with bash and jq, and not familiar with Zig, , it’s easier for me to review bash and jq.
I don’t believe there’s a strong preference one way or the other. It’s been suggested before that a track’s tooling should be implemented in that track’s language when possible. That lowers a barrier for potential contributors who would only need to know Zig. However, like Isaac said, that in turn raises a barrier for guardians reviewing tooling PRs who would then need to be familiar with Zig to get the full picture.
Unless there’s a compelling reason to use Zig, I’d lean towards bash + jq for maintainability.
The compelling reason is as you stated… it encourages those that are learning, mentoring, and maintaining Zig to be able to continue to work in the language.
It shows the language supporting itself. But that is the only reason that I would encourage it.
The ease in which others can help to maintain the track tooling in a general way definitely has its benefits.
It is truly up to the track maintainers to decide which way to go.