@Nico Yes, sorry: on re-reading it, I realize that my comment was rather ambiguous without further explanation of why I added it here …I’ll blame it on my Sunday brain :D
First of all, I very much concur: the redirect discussion as such does not belong here, neither was that my intention.
I wished to highlight that, while this is indeed most welcome for reducing cases like
example.com/i-add-the-title-later, it may also increase cases of “I changed the URL of this article our marketing team shared on all the social media channels two hours ago” without editors’ awareness that they may break things. As you point out, the situation would technically be no different from the current state. But by making the slug setting significantly more prominent in the context of another user task, such UI change may amplify this underlying challenge - a potentially unintended consequence.
letting the use see right there that the slug would still be the same when he changes the title (with the option to manually changing the slug as well or re-generate it form the new title) is the right degree of agency IMHO.
It is. But what the user does not see (neither currently nor with this UI improvement as such; I’ve solved this with customizing the Panel in the past) is that keeping it the same may in many sitations be favourable (yet, should remain possible, i.e. setting changeSlug to false is not practical). So my point - that indeed was not clear enough in above posting - is to motivate a discussion whether this “risk of breaking things” should/can be addressed on the UI level as this feature is being worked on? That’s why I considered the redirect issue on-topic here.
For example: Could there be a note that appears in the context of the slug field of published pages; this could be optional, with a customizable string, to be configured in a page blueprint?