There's no way to undo memory changes in windbg?

When doing live debugging, there's not much use of an undo functionality in general. If a thread ends, you can't simply recreate it. If you step over a line, you can't easily go back to the state before. If you close a file handle, you can't easily reopen it.

If you changed memory, when should WinDbg disable the ability to undo that? Once that memory was written to by the process? Or do you want to be able to undo even if the memory was written to after your edit?

To what memory content should be undone then? To the values you entered (i.e. undo the action done by the process) or to the values before you entered them (i.e. undo the edits made by you, including the changes made by the process) or undo only those values which were edited by you and not changed by the process yet?

As you see, implementing an undo functionality in a debugging scenario can become really difficult. IMHO, WinDbg was never designed to have undo functionality.

I would even say people do not use the memory window to edit memory content. Why that?

When you do a debugging session, you want your steps to be recorded so that you yourself or someone else can verify and reproduce your actions. In such a scenario, you use .logopen and log everything you do. Actions done outside the command window will not be recorded and thus break the verification workflow.

What do you do instead? You use one of the display commands (db, dd, dp or similar) to show the memory contents before the edit. You then use an edit command (eb, ed, ...) to change the memory. Whenever you want the old values back, you look at the previous output of the d command and e those values again.