Allow same From/To state

I'm going to be bold and reopen this as a feature request.

The comments on this issue and the related #2951243: Don't allow transitions to the same state → include a number of proposed use cases, some of which I think are valid to the definition of "state machine" as implemented and others are a bit more tangential.

I _think_ we can stipulate that by an academic definition of a state machine (as linked to a few times already) that "transitions" to the same state value are allowed in theory, and of course do not change the resulting state value.

The question at issue might be as much about terminology as anything else. The example in #6 about sending email when going from published to published could be seen as "trigger this 'transition' to send an email" or it could be seen as "re-publishing," whatever that means, and an email being sent is merely a byproduct. I disagree with the use of a state machine simply to trigger a specific action. If the intent is only to communicate that the "transition" has occurred, then I think that's valid.

The example of a dimmer light switch on the other issue is pertinent here. The transition is on to on, and a subscriber to this transition might choose to brighten the light or, if the brightness is maxed out, do nothing.

In my case, a foreign system is rebilling the user. I want to be able to respond to this information, however it doesn't change the actual state of the membership.

I think this is related in spirit to the recently-fixed #3083407: Fire intended events when invoking a specific transition → where two different transitions have the same definition but different names. The intended transition conveys important information to observers of the transition. It's not sufficient to just emit an event for one of the matching transitions; the intent information is lost.

This is also related to ✨ Support third-party settings on transitions Needs work which discusses attaching/communicating/storing additional information about a state transition.

Slack conversation: https://drupal.slack.com/archives/C1TLCCF9B/p1682009973554299

RTBC on my side, I approve of this change. It's what we discussed on Slack and should have no consequences. The one side effect I could imagine is manually setting the value and our preSave and such hooks triggering. They do not, only if the applyTransition is called to set the internal flag.

Added draft Change Record → .

@bradjones1: Committed! We shouldn't forget to publish the change record :).

I published it :)

Yay! Thanks to everyone who provided input on this concept and for the maintainers for entertaining this, even though it doesn't necessarily benefit Commerce Core in the near-term. I think state machine has a bright future in many applications, not just "strictly" commerce.

Automatically closed - issue fixed for 2 weeks with no activity.