drupal_find_theme_templates() may be unreliable when using nested themes

I agree with this concern.

Just to clarify:
file_scan_directory() does give priority to files in the parent folder.
But it does not have a predictable way to prioritize one subfolder over another. It cannot know that "/templates/" belongs to the parent theme, but "/subthemes/child_theme/" belongs to the sub-theme.
The only way to make this distinction would be to look for *.info files in subfolders, and stop there.

Imo, file_scan_directory() is doing too many things at once.
It would be easier to fix this, if we knew that this function was only used to scan for theme templates.
Since it is used for all kinds of arbitrary and unrelated stuff (also in contrib), we need to be super careful for side effects.

Confirmed this bug in D8 and D7. This happens because drupal_system_listing() is called to index the results by 'name', which if there are multiple templates with the same name in the directory, will only return one result. This will be a problem when the first result found is not the desired theme that is actually being searched.

Given this structure:

mytheme/
  - mysubtheme/
    - templates/
      - page.tpl.php
  - mytheme.info
  - templates/
    - page.tpl.php

The results of drupal_system_listing('/\.tpl\.php$', 'sites/all/themes/contrib/mytheme', 'name', 0) only returns one result, which is unexpected, there were two files that ended with .tpl.php!

array (
  'page.tpl' => 
  stdClass::__set_state(array(
     'uri' => 'sites/all/themes/contrib/mytheme/mysubtheme/templates/page.tpl.php',
     'filename' => 'page.tpl.php',
     'name' => 'page.tpl',
  )),
)

Now, if we change the 'name' parameter to 'uri' to ensure that results with the same filename are included, we do get two results

array (
  'sites/all/themes/contrib/mytheme/templates/page.tpl.php' => 
  stdClass::__set_state(array(
     'uri' => 'sites/all/themes/contrib/mytheme/templates/page.tpl.php',
     'filename' => 'page.tpl.php',
     'name' => 'page.tpl',
  )),
  'sites/all/themes/contrib/mytheme/mysubtheme/templates/page.tpl.php' => 
  stdClass::__set_state(array(
     'uri' => 'sites/all/themes/contrib/mytheme/mysubtheme/templates/page.tpl.php',
     'filename' => 'page.tpl.php',
     'name' => 'page.tpl',
  )),
)

Note that what happened before is that since sites/all/themes/contrib/mytheme/mysubtheme/templates/page.tpl.php was found second, it overwrote the first result, since the return value was keyed by filename, and both filenames were 'page.tpl.php'. What happens originally is then since the one result returned was in a subtheme path, it was excluded as a candidate template for page.tpl.php, leaving no more results. Which then falls back to using modules/system/page.tpl.php, when we just wanted to use sites/all/themes/contrib/mytheme/templates/page.tpl.php!

Patches for D8 and D7 attached. Likely needs tests.

7 years later, the issue still exist.

Only this time this is in: \Drupal\Core\File\FileSystem::doScanDirectory at web/core/lib/Drupal/Core/File/FileSystem.php:707:

if ($handle = @opendir($dir)) {
      while (FALSE !== ($filename = readdir($handle))) {

Can we work on this, so that in ext4 filesystems, this will not mess up themes?

More info about my situation are here: #3329810, #3316641 (with full easy reproduce)

Can we use scandir instead?

(scandir(string $directory, int $sorting_order = SCANDIR_SORT_ASCENDING, ?resource $context = null): array|false)