Should MessageDialog's CancellationToken honour DialogResultOnCancel like Escape does?

A MessageDialog can end without a button press in two ways, and the two disagree about what to return.

In MessageDialog.WaitForButtonPressAsync, pressing Esc or Alt+F4 honours the setting:

tcs.TrySetResult(this.DialogSettings.DialogResultOnCancel
                 ?? (this.ButtonStyle == MessageDialogStyle.Affirmative
                        ? MessageDialogResult.Affirmative
                        : MessageDialogResult.Negative));

Cancelling MetroDialogSettings.CancellationToken does not:

tcs.TrySetResult(this.ButtonStyle == MessageDialogStyle.Affirmative
                     ? MessageDialogResult.Affirmative
                     : MessageDialogResult.Negative);

So a caller who sets DialogResultOnCancel = MessageDialogResult.FirstAuxiliary for a Save / Discard / Cancel dialog gets FirstAuxiliary from the keyboard but Negative from the token.

Not a regression

DialogResultOnCancel came in with ebee93f8 for #2619, and that request was explicitly about the keyboard:

allow the caller to select the default "Escape" / cancel action

So the narrow scope was deliberate at the time, and the token path was simply never part of it. Raising this as a question rather than a bug report for that reason.

Why it still seems worth aligning

• The property is named DialogResultOnCancel, not DialogResultOnEscape. Firing a CancellationToken is about as literal a cancel as there is, so the current split is surprising.
• MessageDialog contradicts itself: two code paths that both mean "closed without a button press" produce different values.
• The other dialogs do not have the split. In InputDialog the token, Esc and the Cancel button all resolve to null; MessageDialog is the odd one out.

Options

Align — have the token path use the same DialogResultOnCancel ?? (…) expression as the keyboard path. One line.

It is still a behavioural change, so it belongs in a minor release with a note. The blast radius looks small: only callers who both set DialogResultOnCancel and cancel through the token are affected, and for them the new value is very likely the one they were already expecting.

Or clarify — if the behaviour should stay as it is, the property's XML comment could say that it applies to the keyboard only. The name on its own suggests otherwise, and nothing in IntelliSense corrects that impression today.

Either way the current behaviour is now described on the message dialog docs page.

Environment

MahApps.Metro version: v2.4.11 (and develop)

Start in MessageDialog.WaitForButtonPressAsync and compare the CancellationToken path with the Escape/Alt+F4 path, using the issue's examples to understand the differing results. Decide whether cancellation should honor DialogResultOnCancel or whether the property's XML documentation should limit its scope; done means the chosen behavior is consistent and the message-dialog documentation or release note reflects it.