I think that a server should be allowed to be liberal in what it accept and thus try to handle such a conflict if it believes that it can do so (in line with the Robustness principle and such) and if it can't then should return an invalid_request error as it should with any validation error that it stumbles upon: http://micropub.net/draft/#error-response

Reading up more on error responses it seems impossible for the endpoint to deliver a message to the client that tells it that the reason for the failure is due to the slug conflict – if one would add a field for a message suitable for the end user, similar to the error_description that's meant for devs, then that would solve this issue I think.

"slug" isn't defined by the Micropub spec, and isn't actually mentioned in the document at all, nor is it mentioned as a property of an h-entry.

There is some experimentation being done with "slug", for example Quill includes a field for it. However this is experimental, and may or may not end up in h-entry or Micropub as a result.

Regardless, systems that include a "slug" field typically take it as a suggestion, rather than as a unique identifier for the post. The "slug" is usually only part of the path of the URL, for example the common pattern in Wordpress sites of /{year}/{month}/{slug}. If the slug is part of a unique identifier for the post, Wordpress for example will append things to the end of the slug to make it unique.

I am closing this issue since it does not apply to Micropub at this time. Further discussion can take place on the IndieWeb wiki: https://indieweb.org/Micropub-brainstorming