While I agree on having few states only, having a single end-state only is not possible AFAIU: It makes a difference whether ever one was a member (was in state “approved”) or not.
If one was a member, there might be reasons to revive the membership, thus there needs to be a transition from “terminated” back to “approved”. While a “rejected” workflow must only go back to “draft”.
If we can make buttons a) set another fields value and transition and b) transition the state based on some field value, we could use less end-states. Example code is welcome. For now “Terminating” reasons would be: rejected, quitted, expelled, death, other.
Regarding moving “reason for termination” into third party modules: I’m strictly against doing so, since it is important to know whether was expelled or not - as discussed in length elsewhere.
Whether a party is a member depends on the reporting date, as described in the design document and discussed in Reporting date - passing date to search in list-view - #4 by htgoebel . I there is a solution taking this into account, I’d be happy to see an example code.
And historization of the “member” record does not solve this issue, since today I enter the termination date at the end of the year. So *tomorrow it will still be a member, but the record is unchanged.