This behavior seems to be a deliberate design decision[1]; it
actually makes some sense, since you don't want to get the
basename only for symlinks, and mixing basenames and paths could
be confusing an error prone.

This needs to be documented, though.

[1] <https://github.com/php/php-src/blob/php-7.4.15/ext/spl/spl_directory.h#L139-L143>

I noticed this testing something where I needed both FOLLOW_SYMLINKS and KEY_AS_FILENAME as well.

I've submitted https://github.com/php/php-src/pull/6695 to change the behavior and test even though there might be disagreement about whether this is intentional behavior...

[email protected] FilesystemIterator::getFilename() work in any case, symlink not pathname - FilesystemIterator::key() mix links and paths - it's too wrong. FilesystemIterator::FOLLOW_SYMLINKS change keys of FilesystemIterator, but manual says:
> makes RecursiveDirectoryIterator::hasChildren() follow symlinks. 

[email protected] your test for php8, I display results for php7

$iterator = new FilesystemIterator(__DIR__, FilesystemIterator::KEY_AS_FILENAME);
foreach ($iterator as $key => $value) {
    var_export(strpos($key, __DIR__ . DIRECTORY_SEPARATOR) !== false);
    break;
}
$iterator->rewind();
var_export(strpos($iterator->key(), __DIR__ . DIRECTORY_SEPARATOR) !== false);

$iterator2 = new FilesystemIterator(__DIR__, FilesystemIterator::FOLLOW_SYMLINKS | FilesystemIterator::KEY_AS_FILENAME);
foreach ($iterator2 as $key => $value) {
    var_export(strpos($key, __DIR__ . DIRECTORY_SEPARATOR) !== false);
    break;
}
$iterator2->rewind();
var_export(strpos($iterator2->key(), __DIR__ . DIRECTORY_SEPARATOR) !== false);

// result: false false true true
// tested on PHP 7.3.26, Windows 10, MSVC15(Visual C++ 2017)