Uniqueness needs a defined scope
AEAD constructions commonly require distinct nonces for new encryption under one key, avoiding reuse of critical state. Counters or a device prefix plus counter can supply uniqueness; a nonce is not necessarily a hidden random password.
The construction defines scope and length. Independent processes sharing a key can collide even if each local counter never repeats, and restart recovery must not reuse old values for new encryption.
References: [1]
Unique, unpredictable and fresh are different properties
Some challenge or initialization uses also need unpredictability, while others require defined uniqueness. A counter can be unique but predictable, and random choices have collision probability, so one generation rule does not describe every nonce.
NIST DRBG initialization has its own nonce contract and distinguishes it from secret entropy input. Adding a public unique value does not necessarily contribute equivalent secret entropy; sequence, time and randomness must be assessed by the guarantees each supplies.
Replay protection also needs binding and state checks
A nonce can travel with ciphertext or be reconstructed by the receiver and participates in authenticated decryption. A mismatch normally fails verification, but repeated presentation of an intact valid message still requires protocol replay checks.
Replay defenses bind the value to the message and context and define prior use, allowed reordering and expiry. A public distinguishing field does not itself prove sender identity, trustworthy time or authorization; algorithm inputs and application permissions remain different layers.
References: [1]