My quick thoughts:

• This doesn't need to happen before v0.3 since it's a non-breaking addition to the API
• We should not rush this to allow more time for review from interested parties since it may be a controversial change
• There needs to good justification for why this should exist. You suggest seeding hash-maps but are there legitimate use-cases where the secure random data is not yet available and the application would not need to block anyway?

This doesn't need to happen before v0.3 since it's a non-breaking addition to the API

In its current form, yes, it's. But I haven't decided yet on which approach to use. Alternative proposals in the issue suggested to use an "option" argument instead. So I would like to sort this out as part of the v0.3 release.

are there legitimate use-cases where the secure random data is not yet available and the application would not need to block anyway?

Seeding of hash maps and non-security-critical PRNGs are both legitimate use-cases. For example, see discussions about issues with systemd which led to the introduction of the GRND_INSECURE flag.

In its current form, yes, it's. But I haven't decided yet on which approach to use.

Then it could be added in v0.4. I avoided putting out many breaking releases for rand because moving to a new version can be a big deal for users, but I don't think that should be the case with getrandom.

Seeding of hash maps and non-security-critical PRNGs are both legitimate use-cases. For example, see discussions about issues with systemd which led to the introduction of the GRND_INSECURE flag.

Yes, systemd is a special case because it operates in an early boot environment. But precisely because this is a special case (and also very targeted to a specific environment) it probably isn't going to use a general-purpose library like getrandom. I would expect most other applications needing to deal with early boot to be special cases which wouldn't want to use a general-purpose getrandom library too (I may be wrong, but until I see evidence I will assume that is not the case).

Hence "systemd needs this" is not good justification for this feature.

Possibly of note is rust-lang/rust#130703: introduction of what is effectively getrandom within std. The internal code does use insecure seeding for hashmaps but the public API proposed here only exposes secure seeding.