user_delete() should not remove the content created by user

We just released code which syncs user accounts to Active Directory accounts. Shocked to see that 20% of our site's content was also deleted as one of the editorial team had recently quit the group (so no longer listed in AD). Never knew about user_cancel() but if it's required at all, should the default case not ALWAYS be to NOT to delete content?

Looking at what all else was wiped; although this editor also created a lot of taxonomy terms and even though those are not specifically tagged with an owner; they do, for some reason, have a translation owner. But those did not get deleted. Nor did any of his blocks. So seems a bit inconsistent - and silly.

As it is somewhat related; i never understood the options when using the UI:

• Disable the account and keep its content.
• Disable the account and unpublish its content.
• Delete the account and make its content belong to the Anonymous user. This action cannot be undone.
• Delete the account and its content. This

action cannot be undone.

- Why an option to assign to Anon? Would this not give anon access to all this content (perhaps not?).

- Why is the obvious (and preferred default) option not even listed here: delete user and assign to UID 1?

Assigning to anonymous doesn't give users access to edit content, unless you set up permissions to give anonymous users editing permissions explicitly.

Assigning content to user 1 would mean that on Drupal.org a deleted user's content would appear as if it was authored by Dries. On many other sites that account is blocked.

I don't see how this would be preferred over assigning to anonymous.

Changing the default to assign the content to anonymous (or anything less destructive) seems like a good idea but probably best in a new issue.

I guess for better and self-explaining DX there should be an API method like

$user->cancel();

which by default respects the configured cancel method:

\Drupal::config('user.settings')->get('cancel_method');

when canceling the given user.

It could also provide an optional argument to override the cancelation method:

$user->cancel('user_cancel_block');