Discard draft and publish draft are fine for the casual user. All the rest is noise.

The only thing that might be useful in more advanced wortkflows is "store draft as version", to later be able to come back and check the evolution of a document (we obviously can not let the editor pick a draft for comparison in a list with the 16500 draft version which have been autosaved)

Thanks you for an advise. It's a good idea to let user save draft as a version, I'll check where would be a more appropriate place for this control in the new editorial interface (may be, it would be wise to keep this with versions inspector tool in page section). I'll check out later also the way our users work with versions, have currently too few infos on that.

Random bullet points that come to my mind while reading your post:

• with the ezautosave extension, the Store Draft button is already hidden because it's useless
• the Store Draft and Exit button was kept because of several reasons:
  • if the user wants to go away and wants to keep its current state we have to propose him a way to properly quit the edit form (all others links in the page are disabled at least in the admin interface to avoid loosing your draft because before ezautosave, the saving was a manual operation and it's difficult to change this behavior in an extension while keeping it if the extension is not there...)
  • the current wording is probably very bad
  • if you close the window or hit the back button or click on any active link, a JavaScript code is executed to save the draft, so you might think the store Store Draft and Exit button is useless since it should done automatically, unfortunately this is unreliable in some browsers (mainly Chrome if I remember correctly), so the Store Draft and Exit button is the only way to be sure that you won't loose any input.
• A detail that might not be clear for everybody: we don't pile up versions, I mean each "autosave request" update the same version object and if the user does not "send for publishing" the version, the end user will be able to get it back later

My 2 cents:

1. Word does prompt you for the version if it's auto-saved a draft and you leave the system (e.g shut off the computer).
2. I'd suggest using terminology (at least for English) from existing applications (e.g Gmail, Google Docs or Wordpress), where applicable.  
3. If auto-saved revisions are stored, then filtering on the revision timeline (content/history) would be useful (hide drafts, drafts only, or date/time etc)

Quote from Damien Pobel :

• A detail that might not be clear for everybody: we don't pile up versions, I mean each "autosave request" update the same version object and if the user does not "send for publishing" the version, the end user will be able to get it back later

I think Jurij is going for more "big sky" thinking here, rather than the current functionality/model?  I wonder whether a light-weight revision (patch) model for drafts that only lasts until the draft is published would be feasible.

Quote from Geoff Bentley :

I think Jurij is going for more "big sky" thinking here, rather than the current functionality/model?  I wonder whether a light-weight revision (patch) model for drafts that only lasts until the draft is published would be feasible.

I know, Jurij and I are working around this topic on a daily basis

But we are trying to make changes in an existing software while keeping a backward compatibility, we have a limited capacity and we have a limited timeframe to make the evolutions (the next entreprise release is planned for the end of the year) so we are obliged to be pragmatic and take the existing features/limitations into account to move forward smoothly toward new ideas and concepts otherwise we won't be able to do anything.

The patch idea is indeed a good one. We could for instance store more or less what is posted when a change is made on a version so we can "replay" the evolution of a draft on a timeline.

 Cheers

Quote from Damien Pobel :

Quote from Geoff Bentley :

I think Jurij is going for more "big sky" thinking here, rather than the current functionality/model?  I wonder whether a light-weight revision (patch) model for drafts that only lasts until the draft is published would be feasible.

I know, Jurij and I are working around this topic on a daily basis

Good to hear  I know, I know, I think there's always that tension between ideals and timeframes (it's constant challenge for me).  I still think it's good to aim high, but have stepped goals so the process can be evolutionary.

Cheers,
Geoff