function wp_unique_post_slug inconsistent for numerical page slugs, e.g. 404

[arve5]

if ( $post_name_check
                        || in_array( $slug, $feeds, true ) || 'embed' === $slug
                        || preg_match( "@^($wp_rewrite->pagination_base)?\d+$@", $slug )
                        || $is_bad_hierarchical_slug
                )

Will always return true for preg_match as long as 'page' is optional and it is a numerical slug, e.g. 404

preg_match( "@^($wp_rewrite->pagination_base)?\d+$@", $slug )
preg_match( "@^(page)?\d+$, 404") => 1

Assuming pagination is the point for this check, a possible solution could be to check if post pagination navigation exists first.

$pagination_based = get_the_post_navigation() ? preg_match( "@^($wp_rewrite->pagination_base)?\d+$@", $slug ) : false;
if ( $post_name_check
                        || in_array( $slug, $feeds, true ) || 'embed' === $slug
                        || pagination_based
                        || $is_bad_hierarchical_slug
                )

Suggestion: Either allow numerical slugs if it does not interfere with paginations, or disallow it with a warning.

[SirLouen]

@arve5 I don't fully understand what you are expecting

Numbers are not valid and they will end as -2 as you can observe through that regex.
Related #63508, got closed for pretty much the same reasons of this topic.

Suggestion: Either allow numerical slugs if it does not interfere with paginations, or disallow it with a warning.

Anyway to this extent, I agree with you, I also had to dig further back in the day to identify the culprit of why the numeric slugs were "disallowed" inside hierarchical posts. I could not find clear docs on why this was happening.

The only way to override this is by shortcircuiting pre_wp_unique_post_slug.