> When I instrumented the function 'foo', it entered edebug
 > between 'y-or-n-p' in
 >
 >    (y-or-n-p "Configuration saved ...")
 >    (delete-other-windows window)
 >    (kill-buffer buffer)
 >    (y-or-n-p "Configuration reset ...")
 >
 > So I supposed that maybe from 'delete-other-windows' and 'kill-buffer',
 > but now I understand this is because exiting the minibuffer from
 > 'y-or-n-p' calls 'set-window-configuration'.

Unless 'read-minibuffer-restore-windows' is nil.  Saving and restoring
the configuration with 'y-or-n-p' makes no sense because in practice the
user cannot change the configuration while 'y-or-n-p' is in progress.

 >> We could add a new field to the buffer structure and a function
 >> say 'buffer-last-name' which would return the last name a buffer had
 >> before it was renamed: nil for a new buffer, the old name before the
 >> last 'rename-buffer' and the last buffer name for a dead buffer.
 >
 > Looks nice.

I attach a patch.

 >> And always think about what to propose when a new buffer with the same
 >> name has been created meanwhile.
 >
 > Something using uniquify could help.

Maybe.  Here I had problems with uniquify not always restoring the base
name of a buffer when I killed the last other buffer with the same base
name.  Maybe the fault is all mine.

 >> 'kill-buffer' calls reset_buffer_local_variables which scans the local
 >> variables alist of the buffer and resets all values to their default
 >> values.  Giving the variable either a 'permanent-local' property or
 >> binding the default value to the buffer local value around 'kill-buffer'
 >> could work around that but I'd rather try to save this (and other buffer
 >> local values) in a separate alist for buffers stored in a configuration.
 >
 > To save revert-buffer-functions like saving positions of dired files
 > in window parameters?

For example, yes.

martin