The “corrective receive” isn’t very clear in the documentation (which can be said about many things related to ZFS).
I’m not even sure if invoking -c on the receiver’s side will prevent it from “rolling back” to the specified snapshot.
For example, if you force the destination to receive a replication stream (even incremental), it will destroy all newer snapshots. Will this be irrelevant if you invoke -c? Will it, in a sense, “insert” the stream of blocks, without affecting newer snapshots on the destination?
Who knows. They developers are vague, which is no surprise.
Super helpful, huh?
EDIT: You also have to love this part:
As if we keep a ledger of what files/blocks specifically exist between which snapshots. 
[1]
When the feature was first teased (before Open ZFS 2.2.0 was released), I thought it would be truly fleshed-out. I was under the assumption that it would know which blocks are corrupted, and only send the correct versions of those blocks from a known good source. (Sort of like how a device in a mirror vdev does that within the pool itself.)
But nope, they just started with a good idea and forgot to actually follow through with a practical usage.
Remember, it’s not good enough to know that a block exists in a snapshot. You need to know between which snapshots it was first created. Otherwise, you’ll have to send a full replication stream, instead of a small, incremental one. ↩︎