Sorry, I do not like what is going on here. It a no no. I will write more, later.

@Fedik wait, this will probably completely rewritten.

I see what you trying to do. And I am not sure if it good or bad.

Currently we have 2 kind of rendering path: tmpl layout and layouts layout. As following:

tmpl layouts:

PluginHelper::getLayoutPath (for default):
  templates/templateName/html/plg_foo_bar/tmpl/default.php
  plugins/foo/bar/tmpl/default.php

ModuleHelper::getLayoutPath (for default):
  templates/templateName/html/mod_foobar/tmpl/default.php
  modules/mod_foobar/tmpl/default.php

HtmlView::loadTemplate: template view/tmpl => component/view/tmpl

tmpl sublayout:

Sublayout will look for: default_sublayout.php

layouts:

FileLayout (for foo.bar):
 ..componentName/layouts/foo/bar.php
 ..templateName/html/layouts/foo/bar.php
 layouts/foo/bar.php

layouts sublayout:

Sublayout will look for: ...layouts/foo/bar/sublayout.php

I am not sure if it a good idea of merging them (as you doing in PR), and use FileLayout for lookup of tmpl/ layout.
Maybe we have to migrate module/plugins to layouts/? Or does it makes no sense?

Also maybe we can create a layout class for each extension (if we decide to migrate to layouts/):

// Modules
class ModuleLayout extends FileLayout{}
// Plugins
class PluginLayout extends FileLayout{}

Each will have own method getDefaultIncludePaths()

About LayoutRendererTrait:
I would keep it simplier, just one method:

function getRenderer(string $layout, array $options = []): FileLayout {}
// or
function getLayoutRenderer(string $layout, array $options = []): FileLayout {}

and remove render(), isDebugEnabled(), getLayoutIncludePaths(), this can be set in getRenderer(), or with $options.

Would be good to hear other opinios about the topic.

Maybe we have to migrate module/plugins to layouts/? Or does it makes no sense?

That was one goal for Joomla v4 but we never accomplished it. @wilsonge can confirm this.

The parts about sublayouts are totally valid (but I haven't play around with the code to see if there's a (not over engineered) way around it).

FWIW I was always in favour of having one and only one template/layout/(call it whatever you want) system.

Thanks @Fedik for your input, really appreciated.

Maybe we have to migrate module/plugins to layouts/?

I would leave it as files in tmpl/ are meant to have a real world usage while the ones in layout/ are mainly used in files in tmpl/. So like that we have a clear distinction. Now the question arises if we really should use the rendering engine of layouts/ for tmpl/ files.

Also maybe we can create a layout class for each extension

In which namespace would you put the ModuleLayout and PluginLayout classes? I would leave it but can change if others prefer extra classes.

I would keep it simpler, just one method:

If we have extra classes, then no method is needed at all.

In which namespace would you put the

I think under Joomla\CMS\Layout is fine.

I would leave it as files in tmpl/ are meant to have a real world usage while the ones in layout/ are mainly used in files in tmpl/.

Then name the classes ModuleTmplLayout and PluginTmplLayout. To avoid confusion with regular layouts/, and when in future we will make move to layouts/.

Now the question arises if we really should use the rendering engine of layouts/ for tmpl/ files.

IDK, It just a files lookup, in general. It can work.
Can also be own, but implementing LayoutInterface

The purpose is to get rid of templates everywhere except components for now. Plugins and modules normally doesn't render full pages only parts of it. Do O would move all tmpl files to layouts in the plugin/modules folder.

I thought about the own plugin and modules classes based on filelayout. It doesn't make usage easy in the future, when we want to inject everything which should be in a layout to render like language, user, route what ever. That can't be abstracted if you use a one line call.

Also I think the trait can be used in 3rd l
Party classes for a sole rendering engine, example I maybe it for PDF rendering.

That's a pointless pipedream @HLeithner that can't happen for years and years

I'm talking about modules and Plugins for now which is possible with this PR for modules and Plugins. I know it's not anywhere near for views

For plugins/modules, we probably can try make smooth transition,
with extended lookup that doing a check in tmpl/ and then layout/.

Example layout will be: foobar.default
Then new ModuleLayout('foobar.default', null, ['module' => 'foobar']) will do lookop as following:

templates/templateName/html/mod_foobar/tmpl/default.php (template/tmpl)
modules/mod_foobar/tmpl/default.php (module/tmpl)
templates/templateName/html/layouts/modules/foobar/default.php (template/layouts)
layouts/modules/foobar/default.php (layouts)

And the same for plugins.
Maybe I missed some paths, but it is a general idea.
Then, at some point drop support for tmpl/ in module and plugin.

Pretty hacky and maybe over engineered, but can work.

tmpl for component View will stay, it part of View API.

I'm postpone this for next release, talking about it tomorrow maintainer meeting

@laoneo yesterdays meeting has to change requests.

1. Remove the extract part for now, I'm in favor but concerns about conflicts / unexcpected behavior came up we can do this after more investigation in a separated pr.
2. Move the layouts from the tmpl folder the layouts folder (in the extension folder) and add b/c code to look in the old html folders before the layout folders (and of course deprecate the tmpl folder)

if we use layouts we also should use the file structure of it.

Currently I have no time to make it ready for 5.0. Better to do it right for 6.0 then.