This document reads a bit strange, like an exhortation not to use this technology. I for one am totally convinced... Nevertheless, here are some comments.

At a high level, the document suffers from having an unclear audience definition. Some recommendations are aimed at implementers while others require cryptographic expertise or are even described as research problems. The problem may stem from my own expectations: this level of vagueness could be acceptable in a CFRG document but less so as the deliverable of an IETF working group.

- Terminology confusion around "private key". In the Intro it is a set of OTS keys. But in the Terminology it is the seed for the OTS keys.

- "Limited number of signatures": this is mentioned in Sec. 1.1, with no background information or justification. Please add some explanation or a pointer to where this is described.

- Similarly, Sec. 1.1 mentions special hardware, add a forward reference to where you explain why this is recommended (clearly this makes the stateful solution even more niche).

- A bit more background on parameters would be useful here, because this reviewer keeps wondering why we cannot solve everything with very long counters, e.g. 128-bit long, which would be "essentially infinite".

- 2.2: "split state and/or private key" - what is it exactly, does it refer to (e.g.) multiple cluster members?

- "to guarantee the availability of both the private key and its state across the lifetime of the key" - I'm not sure what this means.

- "no parts of the system are allowed to read any version of the key during procedures which load, write or modify keys" - do you mean to say, any other version?

- "similar assumptions for the verifier" - but I don't think there's any common use case where an ECDSA verifier actively checks the nonce's uniqueness. Moreover, depending on the use case there may be privacy issues associated with CT, and this proposal may address the threat only if verifiers always check the certificate log.

- 5.1: I can guess why "multiple public keys" is a useful thing but it would be better if you pointed out exactly what this solution mitigates. 

- 5.2: please reconsider this advice/section. It veers too much towards defining a crypto algorithm in an otherwise totally operational document. For example, shouldn't there be an RFC to recommend parameters for these things?

- And the same applies to Sec. 5.3.

- And even more so for Sec. 5.6, "Such dynamically extensible constructions are research-class and are not currently standardized or deployed."
It may be better to break Sec. 5 into practical suggestions in one section, and "future research" in another (or an appendix).

- Sec. 6 again defines a new cryptographic algorithm, but the algorithm is not fully specified (see e.g. wording about "domain separation").

- Also, “irreversibly delete” should be tempered: real hardware often cannot guarantee secure erase under all fault models. Consider rephrasing to “delete and render unrecoverable under the device’s threat model (e.g., by destroying wrapping keys)”.