What problem does this address?

Currently, if you begin authoring a post at post-new.php, a post object is created in the database with post_status=auto-draft. If you then leave the window idle for a certain interval, a request is sent to the 'autosaves' endpoint. As part of this request, the Block Editor changes the post_status from 'auto-draft' to 'draft'. See

This behavior feels odd. Before the block editor, it was generally safe to assume that 'auto-draft' items were items that were created without the user pressing any kind of 'save' or 'publish' button, while 'draft' items were those where a user explicitly performed a 'save' action. I'm currently working on a plugin that tries to leverage this distinction. But with the behavior described above, the distinction no longer stands.

I was able to blame the change back to 4944315, where the status change was lumped in with a number of other architectural changes to the way that core data is managed. As part of that PR, there was a brief discussion about whether this post-specific logic belongs in core-data: https://github.com/WordPress/gutenberg/pull/16932/files#r316549679 The assumption there is this behavior makes sense for posts, but not for other content types. I would push a bit further and ask two questions:

1. Does it, in fact, make sense for posts? As noted above, it erases a meaningful distinction between 'draft' and 'auto-draft', which could be leveraged in various ways (for instance, by ignoring 'auto-draft' items when making post queries)
2. Could we introduce a way to prevent the behavior?

What is your proposed solution?

I don't have a specific proposal, but I would like for it to be possible to prevent the status from being switched to 'draft' when Gutenberg sends its 'autosaves' request. Ideally, it'd be possible to intervene here in a general way; in my particular case, it'd be specific to a post_type.

For the time being I can probably work around this by intervening on the server level, perhaps as part of the WP_REST_Autosaves_Controller logic. But this is likely to result in some oddness in the client, for example in the way that the client location changes to post.php after the successful autosave. So, in an ideal world, it would be possible to do something in the client.

Even if this can't be addressed, I'd be grateful if someone could point to more background information on why this change in status was first introduced. Thanks in advance for any thoughts!