- without significant/onerous change to any existing code that uses moodle forms (i.e. if you just have to add $form->enable_autosave() that's okay, but if you have to write whole php scripts, ugh).
- without breaking anything
As long as progressive enhancement principles are followed, I can see no reason why adding autosaving should break existing functionality. Obviously there are many who know the Moodle core a lot better than I, who may know of heffalump traps that I haven't thought about.
- without causing performance problems (do you want to have a manual save button as well/instead of autosave?)
That's another important one to watch out for - autosaving when each field on a form changes does generate lots of HTTP requests (albeit very small ones) which add to the server load. I've certainly found this noticeable in a situation where lots of people are using the form at once, although in an everyday situation it's not caused problems.
As for manual saving as well, I've taken the approach that the manual save button is disabled (or replaced with appropriate navigation), then enabled again if autosaving fails for any reason.
- with an okay user interface (how do you get back to the lost content? what if drafts were saved but you don't want that post, how do you delete? etc)
My inital thoughts are that UI for handling drafts should be kept to a minimum - if a user has saved a draft then subsequently left and returned to a page, the draft they saved should be pre-filled in the form. The draft could expire after a time, if unused. Beyond perhaps a "clear form" or "revert to saved" button when an unwanted draft is loaded, the only need I could see for extra UI is if multiple drafts/versions are saved, which might be an over-complication.