You do not need to create child template to replicate the issue. You can just change this line of code https://github.com/joomla/joomla-cms/blob/6.2-dev/modules/mod_articles_categories/tmpl/default.php#L21 to something like:

<?php require ModuleHelper::getLayoutPath('mod_articles_categories', $params->get('layout', 'default') . '_items123'); ?>

Our ModuleHelper::getLayoutPath is defined to return the module default path if the path for the passed layout could not be found. In this case, ModuleHelper::getLayoutPath('mod_articles_categories', $params->get('layout', 'default') . '_items123'), the sub-layout could not be found, so the method just return the default layout path, which is current file and then the require command will cause infinite recursion

To prevent that, we need to check that returned path to make sure it is different with the path of the default layout before calling require command. But that will make the code unnecessary complicated, so I guess this will be a won't fix issue.

At the very least, something like that would prevent the site from crashing completely, even if it doesn’t, of course, solve the problem at its root.

$layout_items = ModuleHelper::getLayoutPath('mod_articles_categories', $params->get('layout', 'default') . '_items');

if ($layout_items !== __FILE__) {
    require $items;
}

At the very least, something like that would prevent the site from crashing completely, even if it doesn’t, of course, solve the problem at its root.

$layout_items = ModuleHelper::getLayoutPath('mod_articles_categories', $params->get('layout', 'default') . '_items');

if ($layout_items !== __FILE__) {
    require $items;
}

I just wanted to show-case a realistic scenario, just as it happened to me today. If it’s a ‘won’t fixed’ issue, at least it’s now documented in case anyone else runs into the same problem. 😊

At the very least, something like that would prevent the site from crashing completely, even if it doesn’t, of course, solve the problem at its root.

$layout_items = ModuleHelper::getLayoutPath('mod_articles_categories', $params->get('layout', 'default') . '_items');

if (realpath($items) !== __FILE__) {
    require $items;
}

I just wanted to show-case a realistic scenario, just as it happened to me today. If it’s a ‘won’t fixed’ issue, at least it’s now documented in case anyone else runs into the same problem. 😊

You will need to add that ugly check to all module layouts which loads sub-layout like that, which is not something I would do :). In this case, the error happens just because of the wrong layout passed to second argument of the method call.
Maybe a new flag can be added to the method to not return default module layout pass of the passed layout is not found, but it is another discussion. This is still a special case, and still a won't fix for me.

If I’d had the time to get to work on it, I would have created a PR rather than an issue. You’re welcome to close it if you like. I think a notification would be nicer than having the page crash completely because of a module, but ultimately, the only thing that mattered to me was documenting it.

Please think about this as an open discussion. It's just my own opinion, let's wait to hear from others as well

(I agree that notification will be nicer, but it comes with certain cost which I think it is not worth for this)

That’s how I understood you too. If it came across the wrong way, it was a misunderstanding. :) I just wanted to make it clear that I’m not insisting on something here, and that ‘won’t fix’ is absolutely fine from my point of view too.