Please explain why the current implementation makes problem.

Sometimes AutoRecovery fails. Plus, as someone recently pointed out to me,
AutoRecovery is no substitute for saving files regularly. Many programs have an
auto save feature. If an auto *save* feature exists, AutoRecovery would be
redundant. It seems to me that auto saving would make the overall program
smaller as it would have less to do. With AutoRecovery there is all of the
business of a popup box with prompts, etc. after a program crash. With an auto
save feature, the user simply re-starts the program, maybe an error report runs,
and the user opens the file where it was last saved.

In any event, it is only a suggestion. I leave it to you to decide which would
be better.

Reassigned to Requirements

I'm in agreement. I'd rather have an AutoSave feature. Plus, if it's decided to 
keep AutoRecovery, there should be a way to disable AutoRecovery if you don't 
want to use this feature. There doesn't seem to be a way to do this. 

Removing "needmoreinfo" keyword.

On the other hand, it would mean that the AutoSave feature does override the
previous version of the file at each autosave operation. So if the user makes a
mistake after an operation (buggy) that clears the undo log and autosave
happens, there is no way to come back.

The current process is more robust IMHO because it gives the user the decision
to save definitively or not. If you just want to make some trials on a file
without changing it, autosave would be counter-productive.

I don’t know how David Hamel did it, but his Boxer text editor has no problem
with using undo after an AutoSave. The previous file is saved to a backup file.
You have the options to save the backup file in the Boxer>Backup folder, the
same folder the original file is in, or to a named folder. You also have the
option to name File.EXT either File.BAC (default) or give your own extension.
Whatever you choose, you can have the extension replace the original file’s
extension (File.BAC) or add to the file name (File.EXT.BAC). You can have Boxer
overwrite each backup file or save multiple copies. You may adjust the time
between saves. Come to think of it, the undo on Boxer behaves much like the
macro feature.

I have just been burnt by AutoRecovery in my database, and I would like to add
my support for a simple AutoSave feature. Autmatically save at intervals, with a
nominated folder to archive previous versions for safety (would be ideal if a
simple dialog would allow the user to say how many versions to be kept).
Everyone will understand it, and there is very little scope for confusion or
error. The current system is counter-intuitive, ugly and confuses what should be
a very simple task. I cannot see what benefits it provides that outweigh the
negatives.

I disagree. May be that some people would like an "Auto-Upgrade" for the current
document, but I dislike that way and can only accept that as an additional
feature, but never as a replacement for the current behaviour because of the
same arguments as 'hagar_de_lest'. Because of such objections (As long as we do
not have an 100.000 steps undo stack with scope to edits before close and crash)
that this will never be changed in the requested way, so I close this as WONTFIX.

@whitephoenix:
If recovery fails, you still can hope that you will be able to open the old
document. And if not, because it has been damaged (may be because OOo crashed
just during auto save), you would be thankful to have an additional AutoBackup.

wontfix -> closed