I'm trying to reproduce the bug first, and I'm failing so far. I destroyed my wp-env and recreated it to get the latest WP trunk and used release/17.5 branch here but can't see the error. What am I missing, how to trigger the error.

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

Oh it looks like the "early return" we had in place only works in some php versions but not all

if ( class_exists( 'WP_Navigation_Block_Renderer' ) ) {
	return;
}

So in fact, we could have solved this by just moving the class code within the "if" condition and inverting the condition. But this fix works too.

Size Change: 0 B

Total Size: 1.69 MB

_{compressed-size-action}

if ( class_exists( 'WP_Navigation_Block_Renderer' ) ) {
return;
}

So this is considered an anti-pattern then?

Can anyone provide a docs reference which shows which version of PHP started to support this pattern?

Is the problem really a change in how return works? Because in my testing it seems more like an issue of function/class definitions found at the top level of the file being "hoisted" above the return statement:

<?php

var_dump( class_exists( 'Foo' ) );

echo "before return\n";
return;
echo "after return\n";

class Foo {}

This outputs:

bool(true)
before return

Confirming that the function is already defined even though the line echo "after return\n;" isn't run.

Edit: running PHP 8.3.2

@mcsf, I've tried this with PHP 7.3 and 8.0 and got the same result.
It may not be even related to the PHP version.
However, I'm unsure if you are simply executing your test script from a console with php test_return.php, or if you are attempting to include your test script within another script as shown in this example.
Running a single script from a console without using require_once could (theoretically) affect the outcome.