All of these messages would be more helpful with some information about why it wasn't published. Since at this point we can't really know that, maybe this is not the best way to surface this information, or to prepare the UI message.

Perhaps a handler, that's at the end of the handler list, would be a better place?

Thanx @Piedone for the suggestion. I also thought to extend the Context to support something like Validation Result and change the signature of the method in the interface to return the list of errors, but that would be a bigger change.

Maybe at Triage we decide to make more robust changes e.g. we could introduce Cancel to more operations, support error messages etc. - in this PR or another. My intension was to fix that Success messages appeared to the user, although the publish/unpublish was canceled.

PS.
How another handler at the end of the handler list would help (Sorry, I don't get it)? Keep in mind that the Cancel property can be set/unset from any Publishing/Unpublishing handler, based on the business rules of the domain.

I mean, the notification could be displayed from a last handler if Cancel is true. Because it would actually know that publishing was canceled excplicitly.

Yes, you are right. I don't like the 'last' though, because the module that checks a business rule and cancels the operation will depend on the registration order. If cancel is set to true, a message should be displayed with the reason. If another independent rule is introduced, the other handler could display a notification that the operation is 'forced' to complete.

My concern is that I could not find any IContentHandler, IContentPartHandler implementation using INotifier to display a message to the user. If you think that using INotifier does not break the separation of concerns, we could make that change. Although the Controller that displays the Success notification should also inform the user that the operation failed. If a handler that cancels the operation does not send a notification, the user won't see any message.

Displaying a notification from a handler is OK, I think, though it's not that I'm too fond of that either.

It's actually better to have a notification in a controller, but then the context is not there. Unless instead of a bool IContentManager returns some result object with bool if the publish was canceled or not, and with a cancellation reason. Which looks overcomplicated and not nice either.

I'm really not sure. I see the problem, but I don't yet see good solution.

The error messages can be provided by filling errors in the ModelState as the controller will then display these. Or forced using INotifier.

The current session will still be committed, unless some errors were written in the ModelState

Ah, ModelState, of course. So, please add a message to it in DefaultContentManager. You can access the ModelState via an injected IUpdateModel.