Looks good and a test on a fresh installation is flawless.
But what does it mean for users who are using template overrides and have made changes in the index.php?
Is it compatible with th PR #46034?

If they have made a change in their index.php then they already have issues because we have updated that file multiple times

If they have made a change in their index.php then they already have issues because we have updated that file multiple times

@brianteeman Well, I do that on my home page. The override checker shows me if something has changed. I've never had any issues.

thats what i meant

But what does it mean for users who are using template overrides

they could keep the old override or create a specific layout override with their change. Both will work…

FWIW this modular approach makes it way easier to keep track of changes and also is less code for the maintainers…

Is it compatible with th PR #46034?

Yes, although if this PR is merged then probably we should override the layout templates/cassiopeia/html/layouts/cassiopeia/params_evaluator.php and add/remove the assets/inline css there

No problems found with my own child templates with own index.php.
Needs some documentation but seems to be a good solution.

The more I think of it the more I think this (good idea) is something that should be done with a new site template and not with Cassiopeia. every site using Cassiopeia (even without modification) will get a notice in the admin after update that they have to check their template. Creating "worry/extra work" for everyone on update.

@dgrammatiko, Brian makes a good point that all the Cassiopeia sites will have warnings. Is this something for a new template and not the current?

@brianteeman @softforge and anyone else reading this comment, let me give some perspective on why I did this PR. Decision about the PR as always lays to the maintainers.
The why:
I was having a conversation with Ben about the child template that was introduced in 6.0(alpha/beta) and discussing possible ways about the implementation. So at some point I thought it would be better to see/read actual code instead of trying to explain abstract ideas...
Also, I wanted to showcase what an optimal (or a more moderate word here: better) base code for the modern templates of Joomla could look like. I know this should have been done years ago when we introduced the child template and probably this is one of my biggest regrets on that feature, thus the PR...

All in all, the concept of modularized and overridable pieces of layouts is something that should be explored at some point (6.0, 6.x, 7) as the flexibility and maintainability aspects are greatly improved.

The part about having a message on an update is something that could be communicated and personally I don't see it as a deal breaking (but you might say I'm biased)...

I dont think anyone is disputing the benefits and improvements that this change will create. The only problem is the user experience for everyone updating their web site to 6.0. They dont see the benefit they just see another pointless change breaking their sites on an update. No matter how or where you document the change people will see the error messages first and complain. for me its an unnecessary pain point after spending so long telling people how clean and easy updates are now

Valid argument!

Edit: fwiw breaking their sites on an update nothing will be broken! There's only just an annoyance that users will be notified that some files need to be checked after upgrading. The existing child templates WON'T be broken as the entry points are the same and most people just added/removed code in the override (but even if they did in a way were they requiring the parent entry file nothing would be broken, the code is exactly the same but distributed differently)

I put breaking in italics. I am aware that nothing is really broken but that is not what the perception will be

I'm closing this for the moment