TYPO3 Core

Looks good to me, I'd +1 this patch - or I can offer to create one based on this issue? ;-)

Extensions could be called "SuperText" or something like that, many things could end in "text", "next" - or even people shorting their names to "mycoolext".

only from reading the issue, I'm not happy with the suggested sulution at all.
Without debugging and just opend the `PackageArtifactBuilder` I guess following
would be amore proper check for the if condition:

// skip non-composer installation extension paths and if resource paths does not exists.
if (str_ends_with($path, '/typo3conf/ext/' . $extensionKey) || !file_exists($fileSystemResourcesPath)) {
  continue;
}

This check is to rule `legacy` installation extension paths out. As $fileSystemResourcePath is directly
defined before the if as

$fileSystemResourcesPath = $path . '/Resources/Public';

Good catch, and yes, I believe being restrictive on the legacy syntax like this should work out.

I did a small check on the packagist repository, currently these public extensions would be affected by the bug:

aoe/t3deploy-ext
beewilly/form-element-linked-text
bitpatroon/bpn-variable-text
clickstorm/go-maps-ext
cron/eu-cron-context
kitzberger/form-mailtext
localizationteam/localizer-supertext
nreach/nreach-t3-text
teufels/form-element-linked-text

I don't want to hijack things, shall I create a patch based on this?

I initially misunderstood the issue, I thought the extension name would be the culprit, while in fact it is the vendor name (like described).

So a vendor like "next" or "Agencytext" would trigger this.

I implemented Stefans suggestion in a patch, and we could also re-use the existing constant here.

Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81782