I can’t speak for all, but in my use cases and others I’ve seen in the community, there’s a need to run a different set of actions depending on if the user is “cancelling” the dialog or “saving/continuing/etc.” (aka. “not cancelling” - I used this is a generic way of expressing anything that isn’t a cancel, sorry for the confusion).
If ‘X’ and escape were able to be disabled, then the only way a dialog could be ‘closed’ is via a page title button on the dialog (or javascript) which allows the page designer to put action sequences on those buttons and not have to worry that they won’t fire (e.g. as a result of pressing ‘X’ or escape since they wouldn’t be there).
If ‘X’ and ‘Escape’ are still available to the end user, then the page developer needs to be able to differentiate between cancel/save operations with an “close” event because they would likely trigger different action sequences.
For example, if the user presses ‘cancel’/‘x’/‘escape’, the action sequence might cancel models changes while if they press ‘save’/‘continue’ the action sequence might save model changes. Without a way to differentiate (or ensure that the only way to close a dialog is via a custom button) there is no way to handle the different paths. Even with “After Close” or “Run on Close”, you wouldn’t be able to do different things in different situations unfortunately.
Hope I’m making sense 
I think the “easy” solution would be to allow ‘X’ and ‘Escape’ to be hidden/disabled. This would likely avoid the need to even use “After Close” and “Run after close” for most use cases because the only way to close is via a button or javascript.
I think the main reason people need an “After Close” or “Run on Close” is because of the different ways a dialog could close (it’s a catchall). However, without knowing ‘why’ the dialog closed, it’s only somewhat useful.
I think the “ideal” solution would be something like the following:
1) Add “Before Close” events - This would give an opportunity to cancel the close. For example, in “Before Close” a snippet could be called that would return false if the dialog should NOT close
2) Add Global/Page Level Actions - This would allow the definition of a set of actions and assign a name to them. Then, where the action framework is available, you could choose to define a sequence or choose a global/page level action sequence by name. This gives you re-use of action sequences.
With these, you could do something like the following:
Global/Page Level Action Sequence
1) SaveStuff
- Save Models (Account, Contact)
- ReQuery Models (Account, Contact)
2) CancelStuff
- Cancel Models(Account, Contact)
Popup
1) Save Button
- Use Action Sequence SaveStuff
- Close Popup
2) Cancel Button
- Use Action Sequence CancelStuff
- Close Popup
3) Before Close Actions
- Call Snippet which returns false if the dialog should not close
4) After Close Actions
a) When ‘X’ or ‘Escape’ - This would fire only if user presses ‘X’ or ‘Escape’ keys
- Use Action Sequence CancelStuff
b) Final (e.g. analogous to try…catch.finally) Actions - This would fire regardless of how dialog closed but after “When ‘X’ or ‘Escape’” (if applicable) fired
- Can’t think of anything you would need to do here but nice to have the option just in case
