Oh, I think what I had in mind is to pass the (i,j) pair as extra_in to NonceGen, and use rand' := rand_root. But yeah, that’s i) not exactly CounterNonceGen, and ii) not clearly better.
Note that the most natural cryptographic tool to generate rand_{i,j} from rand_root and (i,j), at least from a theory point of view, is an RNG (e.g., ChaCha20) instead of a full-blown hash function. But a hash function is totally fine, it serves as a good RNG, it’s just computationally more expensive. In some sense, the same applies to the internals of nonce generation in BIP327 and even BIP340. We simply picked SHA256 since implementations need it anyway for the challenge hash of the signature, and it’s a bit perhaps a bit more conservative (or overkill, in other words).
nit: I’d call it seed or psbt_seed or rand_seed instead of rand_root. I think that’s the most common word for such a thing.
Hashing the commitment to the txid and the wallet policy sounds dangerous to me. What if you get a second PSBT for the same transaction? (It may very well be the case that I’m misunderstanding …)