ping @parkr

Hey, I think this is a breaking change since it was a feature that was actually added at one point IIRC. So this would reverse that decision and remove the feature.

Hello @parkr, since I am not able to see how exactly this is a breaking-change, (git blame doesn't reveal a concrete usage in the past either), could you please illustrate with an example scenario.

How is this a feature?

@ror3d Please look again. There's no mention of this being a feature anywhere.

@ashmaroli yes, I meant this as a question to @parkr , how is it a feature that the values from a layout that's not currently in use by a page are overwriting the ones for the layout that is explicitly chosen for that page?

Hey, I think this is a breaking change since it was a feature that was actually added at one point IIRC. So this would reverse that decision and remove the feature.

@parkr could you clarify how the bug reported in #9710 could be a feature?

Hey, so my context on this is that this allows layouts which roll up to all provide some data. Maybe you have a "product" layout which specifies certain relative links or breadcrumbs, and that rolls up to a "default" layout which contains author information etc. If you don't merge the layout data, you don't get all of that metadata available in one place. Sometimes you'd want to access the entire collection of layout metadata all in one place.

This is a "power-user" feature for sure, but it's been there for ~years so removing it could be disruptive. It would be a v5.0 change to remove this since it would be breaking.

One alternative (also breaking technically) is to change the order of the merge.

Right, but there is still a bug in that system, as described in the issue I wrote up #9710 . The values from a layout that is not referenced shadow the ones of the layout directly referenced in the document.

That can't be a feature.

Maybe you mean that the PR, by removing the call to Utils.deep_merge_hashes, is breaking more complex use cases, but as it stands right now, the call to it seems to not give priority to what it should, or it seems to be merging stuff that it should not have access to.

Please take a look at the issue to understand the problem that it causes. It's easy to reproduce. Let me know if there is something not clearly detailed.

@ror3d Parker's latest comment threw some light on why the previous change could be considered a breaking-change, at the same time showing the path for a probable resolution.

I have reinstated merging ancestor-layout-data but with a small change of flipping the order of merged objects. This change should in theory fix your reported issue as well. (Do let me know if it doesn't).
I will adapt Parker's example scenario into a Cucumber scenario in the coming days to test probable disruption.

Yeah I think the thing I was thinking of was inheriting (by design) from a parent layout in the tree. But you pointed out that actually siblings (non-ancestors) in the tree were "polluting" the values. That is not right.

Based on the linked #9833, it is clear that front matter data from ancestor layouts are not merged into current layout even on master. So @parkr, what do you suggest that would be the best way forward?