The documentation describes the commit action as follows:
When an object is being committed through a default save button, a commit activity, or webservices, it will always trigger the commit events. The platform will also evaluate all associated objects. To guarantee data consistency the platform will also auto-commit associated objects.
An autocommit is an automatic commit from the platform. That is done to keep the domain model in sync. If your application ends up having autocommitted objects than you have a modeling error. Since an association is also a member of an object, the association will be stored in the database as well. That means if you create an OrderLine inside an Order, with OrderLine being the parent of the association. When you commit the OrderLine, the Order will be auto-committed.
In other words; your logic is correct.
Mark, the logic in your microflow is correct. Mendix does not support the concept of cascaded commits, so you will have to manually commit every single object you want to end up in the database permanently.
Also note that a commit of a child would autocommit its parent, and not the other way around. The reason for this is that a child knows who its parent is, so if you commit the child, Mendix doesn't like it if it would have a refence to a non-committed parent, and will autocommit the parent.
The parent has no idea who their children are, so Mendix does not care if you commit it without committing the children.
Also note, as per Christiaan's quote, that autocommited objects are not "really" committed. They are committed, but will be deleted by the platform when the user logs out (yes, really :( ), unless they are explicitly committed later on.
Thanks for the response. To clarify: is the logic in my microflow correct (i.e. I should commit the list seperately) or is the logic in my OP correct (i.e. I don't have to commit seperately)?