While I have never tested this out, I have a few thoughts:
I am curious what you find.
I was curious about this, so I did some further testing. I created a microflow similar to the one you shared and tried to commit the newly created object in the error handling flow. The commit didn’t throw an error, but the object was not saved to the database. Next I created a new object and copied attributes from the first (rolled back) object. I successfully copied and committed the new object. The original object, while it can be accessed in the microflow, is gone after that.
So it seems to me that this behavior is so that, as a developer, I can recover gracefully from an error, without losing data if I choose not to.
Good question and maybe somebody from Mendix can chime in here. From the documentation
The Rollback object action can be used to undo changes (that have not been committed) made to the object in the part of the flow preceding the activity. Furthermore, it deletes objects that have been created but never committed.
So from the documentation it seems that retaining the newly created object is indeed wrong. I would create a test project and create a support ticket.
There are a couple of different things that I see mentioned here in this thread. I’ll try to explain them all.
Error handling type: custom with rollback
This rolls back the database transaction and allows the microflow to continue on the error handling path. It will not change nor roll-back the state of the objects that are still in memory because they are persisted in earlier microflow activities (either by a Commit-Action or a Create/Change action that has commit set to yes). As a result of that, recommitting the same objects will not cause a change as the runtime no longer knows which members are changed or whether the object was created or not. If you want to change the data in the database again you should indeed copy the changes to another/new version of the same object.
Error handling type: custom without rollback
This will not rollback the transaction in the database, meaning that all successful committed changes in objects within activities of the microflow preceding the current failing activity will stay in the database. The microflow continues on the error handling path allowing you to do different things to circumvent the error.
This is a whole different thing as it will not influence the database transaction. It will remove all changes of the specified object or remove the object from the state when it still was created-but-not-committed. It has no interaction with the database at all.
The observed behavior is indeed the intended effect. If this explanation is helpful I will make sure that this is updated in the documentation.