The nonces that I know of must be unique (non-repeating), but they may be predicable.
Not exactly. The definition of a nonce is that it must be non-repeating. Some schemes that use a nonce have additional requirements on the nonce, beyond being a nonce. Some schemes allow predictable nonces, others don't.
For example, modern AEAD schemes such as GCM and CCM allow predictable nonces (e.g. {0, 1, 2, 3, …} is a perfectly fine sequences of nonces), but many older symmetric schemes have strongr requirements. For example CBC additionally requires the nonce to be unpredictable and uniformly distributed. (CBC calls the nonce “IV” (initialization vector), but that's more because of terminological history than because an IV is fundamentally different from a nonce.) CTR (which calls the nonce “initial counter value”) allows the nonce to be predictable, but requires the counter value for each block to be unique, not just the initial counter value for each message. All symmetric schemes allow the nonce to be published with the ciphertext.
ECDSA has very stringent requirements on the nonce. It needs to be unpredictable and uniformly distributed, but also it needs to remain secret. If you have a message, an ECDSA signature and the nonce used to produce it, you can recover the private key. If you have partial information about the nonce for multiple signatures, that can also be enough to recover the private key. For example, with two signatures of different messages with the same key and nonce (i.e. you don't know the nonce value but you know it's the same for both), you can recover the nonce value and thus the private key. This makes the ECDSA nonce a choice target for side channel attacks on the signature process.
The ECDSA nonce is sometimes given other names such as “ephemeral key”. “Ephemeral key” is technically correct, but is confusing for practicioners since it's very different, for example, from a Diffie-Hellman ephemeral key: you'll never see this “key” as a parameter of a crypto API, it's only an internal detail of the ECDSA signature operation. It can also be called by other names such as “internal random value” (mostly correct, but as we'll see below “random” is actually too strong) or “intermediate secret” (correct but ambiguous). The notation is pretty well established, so it's sometimes called just “$k$”.
The bug in PuTTY was that it generated nonces in the range $[1, 2^{512}]$ rather than $[1, n-1]$ where $n \approx 2^{521}$ is the curve size. This means that every nonce has 9 known bits out of 521. That's known to be bad. It allows the key to be recovered from a little more than $512 / 9 \approx 56$ signatures (each signature with 9 bits known in the nonce contributes to almost 9 bits of independent information about the private key).
The bug was specific to P-521. P-521 implementations are tricky because they're the only popular curve whose size isn't almost a whole number of machine words. That makes P-521 more prone to coding mistakes and side channel leakage than P-256 and P-384. Several P-521 implementations have been vulnerable to side channels that allowed attackers to find out when the top machine word of the nonce is 0, which for P-521 happens with probability $\approx 2^{512}/2^{521} = 2^{-9}$, allowing key recovery from thousands of signatures. Such a side channel is not exploitable for other curves, since for other curves the attacker needs to collect about $2^{32}$ signatures (for 32-bit words, assuming perfect measurements) to get 32 bits of information. In the case of this PuTTY bug, every signature is suitable for the attack, making the recovery very quick.
Bugs like this, where some output is random but not random enough, are very hard to detect by testing. That's why many modern ECDSA implementations use a deterministic variant codified in RFC 6979. The ECDSA nonce doesn't actually need to be a nonce (but it's still called “nonce”), in the sense that it can be repeated for multiple signature operations, it only needs to be unique for a given (key, message) pair. Deterministic ECDSA uses a PRNG seeded by the key and message to create the nonce, instead of random generation. Deterministic ECDSA is less prone to implementation bugs because implementers can test that they get the sole permitted output for a given input. (Deterministic ECDSA doesn't particularly help againt side channel attacks, however; it makes some attacks easier and others harder.)
PuTTY actually used a deterministic variant of ECDSA, but it was older than RFC 6979 and proprietary to PuTTY. The design of this variant was overly fragile: a simple hash of the PRNG inputs, limited to 512 bits. This is insecure for curves larger than 512 bits, and the only curve that's so large is P-521.
