Lambda the Ultimate

My answer addresses semantics and uses practical ideas, not theory. (I don't care about theory.) Since you want practical consequences on a heap, this view might be helpful.

cdiggins: I have generally understood a continuation as being more or less a copy of a call stack, and that it leaves the state of the heap untouched.

A continuation has both state and behavior parts. The state part typically looks like the "stack" for a current thread of execution. It's almost but not quite thread state. But since you can cause a thread to run more than one continuation, serially and interleaved in some fashion, it's wrong to think of a continuation as identical to a thread. Instead, a continuation is what a thread might be doing if it runs. At any given moment, a thread runs at most one continuation. Think of continuations as halfway to fibers (lightweight threads). That's why you can implement OS-like context switching in a language with first class continuations.

The difference between thread and continuation is more interesting in a language whose call stack is actually heap-based, using so-called cactus stacks or spaghetti stacks, where call trees might be physically modelled by linked lists of heap-based activation frames. In languages like C where "the" stack for a thread is typically monolithic and singular instead of fragmented and legion, it's hard to separate ideas of continuation and stack.

If a thread is suspended for any reason, say because blocked by an operating system, then a continuation is what the thread is going to do next. It's the state and register set (etc) one puts back to resume a thread. Such OS thread state isn't typically exposed as a first class type to a programming language (unless you squint while looking at setjmp() and longjmp() in C). When you do expose a continuation as a data type in a language, instead of making it possible to resume control at all possible points of interruption, typically you only allow certain well-defined points in code flow to become continuations. For example, a function's "return address" (and associated stack) in the caller is a good place to let a continuation become visible as a first class object, because languages are often already invested in heavyweight call-tree bookkeeping (which is what can make function calls expensive compared to inline code).

A continuation, as a first class object, is a callable thing which causes the current thread to resume running where it left off when the continuation was captured. However, both stack and heap can change after a continuation is created. And both stack and heap can change each time a continuation is called. You can think of a continuation as similar to a closure with a wilder effect of control flow discontinuity, like exception throwing, except calling a continuation can go either up or down the stack of a call-tree. You might have heard folks say objects are a poor-man's closure, or vice versa. When you have a closure, you can modify state in a closure without making it stop being a closure. Similarly, you can modify state in a continuation's stack without making it stop being a continuation. And the heap can change arbitrarily. So I don't think it's correct to say a heap is untouched; rather, a heap is outside the scope of a continuation, and can change independently.

The behavior part of a continuation is a bit like that of a function. Except each time you call a function you have a new caller, and you get a new activation frame for the function. But when you call a continuation, you get an old caller, with activation frames that existed when a continuation was created. It's like going back in time -- except both stacks and heaps can change between continuation calls, so it's useful and meaningful to call a continuation again, since the world has changed since the last call. It's the "traveling back in time" aspect that makes a casual specification of continuations sound so weird when looking at examples.

cdiggins: I was wondering is if it restored the heap to its original state, would it still be considered a continuation?

In a language with side effects, if a developer carefully arranges specific side effects to occur altering heap-based state, it sounds like restoring a heap to its original state would subvert a developer's plans. A continuation that restores a heap would not look like a continuation to a developer who thinks both stack and heap can change independently.

I am wondering what to call such a construct if it isn't really a continuation.

The feature seems related to First-class Undo or Worlds or Backtracking.