Audit usage of edit_post()

[afercia]

Technical debt ticket. Noticed while working on #64952

To my understanding, ​edit_post() either returns the ID of the edited post or kills execution by calling wp_die().

However, there are at least 3 places in the codebase where the returned value of edit_post() is checked by using is_wp_error(). That seems totally pointless because edit_post() never returns a WP_Error, unless I'm missing something.
See ​here, ​here, and ​here. Only in the third case the check for WP_Error may be valid as the returned value may be in some cases the value returned by wp_create_post_autosave().

At the very least the two first cases should be cleaned up

TL;DR
In a way, edit_post() shows its age. In case of failure, it would be best it returned an explicit value to indicate a failure. I doubt it can be changed because of backward compatibility. If WordPress had a deprecation policy, this function should be deprecated and replaced with a new, better, one. I do realize it's only one of the many cases where WordPress code isn't ideal. However, as the years go by, I personally believe that a deprecation policy is the only way to ensure a better future for WordPress.

[SergeyBiryukov]

Replying to afercia:

In case of failure, it would be best it returned an explicit value to indicate a failure.

We could probably introduce a $wp_error argument defaulting to false, similar to:

• wp_insert_post()
• wp_update_post()
• wp_allow_comment()
• wp_new_comment()
• wp_update_comment()
• wp_schedule_event()
• etc.