Auto-save will not be disabled as it would require significant changes to Inventor’s data model and would go against a lot of the UX changes and goals of the new frontend.
We don’t currently store any data on the client-side since it is expected to be sent to the server via auto-save, so this would require that we begin storing significant amounts of data on the client and build bulk update systems to handle saving many fields at once.
This would make the editor slower on low-end devices, and if it were offered as a toggle (as you suggest), we’d have to maintain two separate solutions for saving data, which is a significant amount of development overhead for a feature that likely would only serve a small portion of users (assuming auto-save stayed the default, which I think would be more sane choice to protect from data loss).
It is also entirely unclear how batched changes would work with Inventor’s real-time/live collaboration, besides causing a ton of merge conflicts or just accepting the last-in request.
In the future, there will be a migration tool for copying flows/dbs/etc. between multiple bots as a ultimate feature, so you can have a ‘staging’ and ‘production’ bot and transfer data between them.
In the meantime, just deactivate the flow (click the 3 dots, then deactivate) while you’re editing it or make it collaborator only. For commands, you can just check the collaborator-only box, for other flows you can use the Is User Collaborator block. You can also remove the trigger or swap to an empty trigger while you’re working on a flow.
Something that has been considered in the past is allowing you to create a ‘change set’. This would basically be a deactivated copy of the flow that you can edit, then one-click save/swap into the ‘parent’ flow, or discard to revert to the prior version.
Change sets would still utilize the current autosave system, but your updated flow would only be published once it is ready. This seems like the ideal implementation to me, but is still a significant undertaking and demand for that sort of feature is unclear. That is somewhat related to version history, which is in a really similar spot (rough idea of how to implement is figured out, but it is a very large feature with unclear demand).
This was brought up a while ago on Discord here.