As a side note, since you brought it up, let’s talk about why saving in a plugin environment is a tricky user design challenge.
Plugins work inside a host architecture. Saving a plugin project saves to that host project data.
As such, when the host fails (in this case, Premiere crashing) the saved data that is lost in the host from lack of saving is also lost in the plugin, because the data persists in the host, not externally.
You may think Premiere auto-saving would help this, but modal plugin dialog architecture does not allow host operations while a plugin modal window is open, so it has to rely on the user or host saving when closing the dialog.
The clear workaround is to always have a persistent backup autosave file in the case of failure, which is how Mocha currently operates.
However, consider a user with multiple projects or multiple hosts: How will a plugin determine which autosave file should be tied to which Mocha plugin project? Multiple projects could have multiple saved backup files from different hosts.
We could use a unique id, but there is no guarantee that a new effect applied to a clip will match the file id of a save file. So, in the case of timestamped effects and their related hosts, we can at the very least provide an autosave load prompt when it appears the last file used was linked to the project you’re currently opening. When that fails, a manual load is required.
All autosave filenames are written as such to provide easier discovery:
This translate to a file being called something like mpp-7_aftereffects-16.mocha.2020-01-29_11-39-13.autosave
You can read more about this in the Autosave section of the User Documentation: